Index
> Projects and Ideas > What I am currently working on.Goto page 1, 2 Next |
| Author |
|
|
JohnFound 24 Sep 2015, 17:41
This post is some kind of report about my work in the moment. Unfortunately the things goes slow, because of my work and home duties, but some progress can be seen.
Currently, I am concentrated on the portable GUI toolkit for FreshLib. The main objectives of the project are: 1. High quality graphics with full featured alpha transparency on all supported systems - including Linux without compositing window manager, KolibriOS, etc. 2. Very easy to add new GUI widgets. 3. As less as possible dependencies on external libraries and OS functions. 4. All graphic processing to be assembly-centric. As in the old DOS days, all the drawing happens in the memory frame buffers, without calling OS GUI functions. From the attachment you can download compiled application for Linux that demonstrates the alpha transparency for some buttons. The sources are of course accessible in the source repository (the branch "NewWidgets"): http://fresh.flatassembler.net/fossil/repo/fresh/index For now, only the Linux OS dependent part are ready, but as long as the needed code is very small, I hope at least the Windows port will be soon ready as well. The project is open, so if you find the project interesting, you can contribute code for different widgets, GUI skins, drawing and painting procedures, etc. EDIT: Uploaded new version with bug fixed, concerning hanging the program on resizing window. EDIT2: Many new fine demos down in the thread. Check the latest posts for update.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 Last edited by JohnFound on 05 Nov 2015, 19:19; edited 3 times in total |
|||||||||||
24 Sep 2015, 17:41 |
|
|
JohnFound 25 Sep 2015, 04:50
Hi sleepsleep. Yes, it should look like this. The fontconfig warning is something new for me. It probably needs some fix.
P.S. Ah, it is probably your config file that needs fixing.  |
|||
|
25 Sep 2015, 04:50 |
|
|
JohnFound 26 Sep 2015, 16:53
With the new GUI framework architecture, the widgets can be with any shape even with holes in the middle.
See the attached example of a button with big hole inside and another button in the hole. Notice, that the holes are not processed as a part of the button.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||||||||||
|
26 Sep 2015, 16:53 |
|
|
JohnFound 26 Sep 2015, 17:53
BTW, the code that makes the hole is simple drawing on the button canvas with fully transparent color:
Code: proc ButtonPaint as TWindow.OnPaint
begin
stdcall DrawSolidRect, [.canvas], 40, 40, 140, 140, 0
return
endp |
|||
|
26 Sep 2015, 17:53 |
|
|
JohnFound 14 Oct 2015, 17:08
Here is the next technology preview demo of the FreshLib GUI toolkit. It tests different aspects of the GUI elements that have at least partial implementation. Some bugs and misbehaviors can be expected.
The source is accessible on the Fresh source repository (links in the first post of the thread).
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
||||||||||||||||||||
|
14 Oct 2015, 17:08 |
|
|||||||||||||||||||
|
typedef 14 Oct 2015, 21:38
As much as I am not fond of the new ubiquitous "flat" design, may I suggest to try that.
It's easy to draw and very fast. Just solid colors and managing the padding and margins. |
|||
|
14 Oct 2015, 21:38 |
|
|
JohnFound 14 Oct 2015, 22:15
The design code and data are planned to be placed (more or less
 ) in a separate skin file, so it will be freely customizable. For now I wrote in a hurry some code, simply to test the features of the toolkit (for example transparency, owner drawing (the form background), the mouse events, etc). |
|||
|
14 Oct 2015, 22:15 |
|
|
JohnFound 16 Oct 2015, 20:09
typedef wrote: As much as I am not fond of the new ubiquitous "flat" design, may I suggest to try that. Indeed, working on the flat style, I fixed many flaws in the drawing and theming code, so it was useful exercise. Here is the result.
The source is committed to the repository. P.S. The icons for the design are downloaded from http://www.flaticon.com/ and then converted by me to PNG.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
||||||||||||||||||||
|
16 Oct 2015, 20:09 |
|
|||||||||||||||||||
|
JohnFound 28 Oct 2015, 17:23
Hi.
Here is the next demo and screenshot from my work on FreshLib GUI engine. This time it is the TreeView control. This demo was able to scan all my file system "/" and to fill inside the tree view control more than 700000 filenames without any lags on the visual appearance. The horizontal scrollbar is not implemented for now, so, the deep trees will not be displayed correctly.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
||||||||||||||||||||
|
28 Oct 2015, 17:23 |
|
|||||||||||||||||||
|
revolution 29 Oct 2015, 02:31
JohnFound: I wonder why you are reinventing the tree view controls. The standard ones work fine right? And because they are standard people are used to how they work and the styling they use, so they don't need to overload their thoughts and have to rethink yet another tree view control.
I have my system tree view controls set just how I want them and I get annoyed when some other program thinks they know better about what I want and do some custom thing that is ugly and/or works less well and/or has fewer features and/or behaves differently and/or uses different keyboard bindings, etc. Or doesn't Linux provide anything standard? That would be even worse! |
|||
|
29 Oct 2015, 02:31 |
|
|
JohnFound 29 Oct 2015, 05:37
revolution wrote: JohnFound: I wonder why you are reinventing the tree view controls. The standard ones work fine right? And because they are standard people are used to how they work and the styling they use, so they don't need to overload their thoughts and have to rethink yet another tree view control. Well, Linux does not provide "standard" tree view control. At least not in the meaning of Windows. There are several different GUI toolkits that provide different controls - for example GTK, Qt, FLTK, etc. FreshLib is just another such library. But of course, there are some common rules about how the GUI controls must look and behave and I am trying to conform with them. The main reason why I am creating independent GUI library in FreshLib is because I need portability for all OSes supported by FreshLib, including OSes that have no "standard" widgets at all - for example KolibriOS and other assembly written OSes that have very basic GUI or even has no GUI at all. The libraries of FreshLib need very little OS support and can be ported for new OS very easy and quick. I will very soon provide an implementation for Windows and a little bit later for KolibriOS and will post some demos here. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
29 Oct 2015, 05:37 |
|
|
typedef 29 Oct 2015, 05:55
The trick with any list related control is recycling the individual item's view.
So if your list(backend array) has 10K items and your view is 100x100 pixels and each listview item is 100x10, you can create only 10 view items and simply update the data instead of creating corresponding 10K views. You'd then add additional views as the parent window gets re-sized, recycling the oldest ones as the current data goes out of view. @JohnFound It looks really nice. This will also give you the added benefit of using vector graphics. |
|||
|
29 Oct 2015, 05:55 |
|
|
revolution 29 Oct 2015, 06:53
JohnFound wrote: Well, Linux does not provide "standard" tree view control. At least not in the meaning of Windows. There are several different GUI toolkits that provide different controls - for example GTK, Qt, FLTK, etc. FreshLib is just another such library. |
|||
|
29 Oct 2015, 06:53 |
|
|
JohnFound 29 Oct 2015, 07:17
revolution wrote: I think you disrespect the user when you decide to override their choice of GUI layout and do your own thing. If someone chooses GTK (or QT, or whatever) as their GUI then just use the GTK controls. Then the user will be familiar with how everything works and can concentrate on the task at hand rather than fighting with a new set of controls. I will always disrespect some of the users. If I choose GTK, I will disrespect the Qt and FLTK and the Windows users. If I choose Qt, will disrespect the users of GTK, FLTK and Windows. If Windows, then the code will be not portable and will disrespect all the Linux users. In all these cases I will disrespect all developers and users of KolibriOS, MenuetOS and all hobby OSes where the FreshLib can be easily ported, but not the monsters Qt, GTK or Windows controls. Of course, I can respect all these users and write different code for Qt, GTK, FLTK and Windows and of course some independent code for the users of KolibriOS. And I am sure, you will like the wonderful native appearance of FreshLib when I release the alpha version in year 2056.  _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
29 Oct 2015, 07:17 |
|
|
revolution 29 Oct 2015, 09:29
Curious. Is it really faster to write custom controls than the simply write code to import and/or bind to the provided standard controls on each platform? How many different toolkits are there for Linux? Thousands?
|
|||
|
29 Oct 2015, 09:29 |
|
|
JohnFound 29 Oct 2015, 09:55
revolution wrote: Curious. Is it really faster to write custom controls than the simply write code to import and/or bind to the provided standard controls on each platform? How many different toolkits are there for Linux? Thousands? The GUI OS dependent code for FreshLib is very very small and have very few dependencies. The GUI controls code is bigger, but it is OS independent. This way it have to be written only once. Then the effort to port it to another OS is really minor and can be made in just one-two days. If I wanted to use the native OS GUI toolkits (and I though about it before) it will need relatively small OS independent code, but pretty big OS dependent code. And as long as the different OS controls are different, I would need to find some common set of features that to support and this set of features will be smaller than the any of the native controls. And on top of all, for the small assembly OSes (like MenuetOS and KolibriOS) the whole GUI controls must be implemented, because there is no such thing like "native GUI toolkit". So, the effort of making native GUI toolkit includes the whole effort for creating "non-native" GUI toolkit and a lot of OS dependent code on top of this. On the other hand, "non-native" toolkit can be made to resemble very closely the look and feel of the native toolkits, simply by using well designed themes. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
29 Oct 2015, 09:55 |
|
|
revolution 29 Oct 2015, 10:39
Do your themes include key bindings? I find one of the most annoying things about other custom made controls is the lack of certain (or all) key bindings or (worse) a change in the key bindings. Many devs seem to forget that not everyone uses a mouse 100% of the time. Also people with difficulty seeing can use some OS features that speak to them to say what is happening and custom stuff often is not compatible.
As an aside: I find the latest trend in browsers to write custom menus and title bars to be very disappointing. It is one of the reasons I haven't upgraded my browser. It makes the frame "special" and inconsistent with everything else. And at times it is confusing and jarring to have to learn a whole new set of operating actions just for one application. |
|||
|
29 Oct 2015, 10:39 |
|
|
JohnFound 29 Oct 2015, 11:07
revolution wrote: Do your themes include key bindings? It is planned for the future. _________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
|||
|
29 Oct 2015, 11:07 |
|
|
JohnFound 29 Oct 2015, 11:55
BTW, here is small screen shot from the Win-like theme.
_________________ Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9 |
||||||||||
|
29 Oct 2015, 11:55 |
|
|||||||||
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|