Aesthetic bugfix of Lazarus's Component Palette

[Martin_fr]

That is also what many office suites do. IMHO also a good solution.

Even better, if it can be detached, and stays open as a window. Otherwise it is a lo of work, if you need to open it over and over again.

BTW: changes may need to be tested with:

EnableComponentPaletteOptions (define when building the IDE)
It is an unfinished attempt (*NOT* by me, I cant take the credit) to add configurable ordering. (hint open options, use drag and drop in options)

[Martin_fr]

Delphi 7 uses TScrollPage, not a TScrollBox.

Also nice. But more work to scroll. (especially if you often need to switch between to items not fitting on one page.)

It can be implemented, using 2 toolbuttons. (Add to LazControls, or directly in the IDE)

What do you think ?

Personally: I am not a fan of TScrollpage.

But I would accept it, if some one would implement it.
Just a hint, scrolling one by one may be slow. So maybe scrolling half/full page, or have 2 buttons with different speed, or allow click + shift key, ..... just ideas)

---------------------

Most other solutions are fine. Getting rid of scrolling IHMO a good idea.

Being able to detach keep open any dropdown: Nice addition, but not a must.

e.g
having (both)
a) none scrollable, single line, +chevron in the main bar.   (though, if it has chevron, it may as well have 2 buttons to scroll sideways)
b) additional window, that can be used optional, containing Accordion

together, would be perfect.

But that is just my 2 cents.

And other solutions are very acceptable. After all, if x2nie volunteers to do more on that, you get to have a choice too. (Just describe it before you do it, so it is somewhere in range)

[taazz]

On newer delphi version (up to delphi 2007 after that I stopped upgrading) you could set the palette to horizontal by checking or unchecking some option but each category was autosize to show all the icons the horizontal scroll bar was scrolling everything including the category containers as if they where a bunch of TgraphicControls with variable number of icons/component inside a tscrollbox. The layout auto placement wend first down then right.

If and I stretch this as much as possible if any one is going to work on the GUI part of the IDE then you must keep in mind that the current layout is awful in windows 8 default theme. It requires a tone more space than on win7, they wend and raised the border size from the classic 2 pixels on each side to around 10 on each side that makes the floating window layout a waste of space, a lot of space and take in to account that the various border styles (bstoolwindow/bsdialog/bssizeable) are no longer distinguishable and everything looks the same you get a pissed of developer.
I'm so pissed with the "new" look that I started working on a custom tabs control that will eventually be used on a custom tpagecontrol which will allow me to define some empty space on the tabs and use it as a caption bar on my applications to allow me to set the border style to bsnone and I will manually handle resizing and moving. Attached my current desktop.

[x2nie]

Okay, while we are waiting for someone else, let's step any possible progress.

---------------
BTW, if you extract your N-order versus Z-order patch. I think that can be applied

Here, in attachment.

[howardpc]

@taazz
Slightly OT, but I'm intrigued as to why you choose an OS that annoys you and hinders code development, or requires time and effort to code workarounds for display issues. What is the compelling reason for your OS choice, then, given the myriads of alternatives? I'm not having a go at you, I'm genuinely interested in (possible) advantages of Win8 over its predecessors and non-Windows alternatives.

[Martin_fr]

While reviewing the patch, I also found a bug in the existing code.

Buttons per row did not take into account the space used by the scrollbar (you found that too).
But you over corrected it. If all fit into one row, then that space can be used.

I made a tiny change to that. I will commit to SVN soon.

BTW with what name should I enter you in the contributor list?

[x2nie]

Buttons per row did not take into account the space used by the scrollbar (you found that too).
But you over corrected it. If all fit into one row, then that space can be used.

Can be used for what?

I made a tiny change to that. I will commit to SVN soon.

BTW with what name should I enter you in the contributor list?

Well, I think "x2nie - Fathony Luthfillah" would be good recognized by my both friends and family.
Only a few of friends knew my real name, and my family never know that I used a strange name in net.

[Martin_fr]

See my commit to svn.

Also see
http://bugs.freepascal.org/view.php?id=26083

So on windows it will be incorrect for now (but it was incorrect before)

[x2nie]

Ohyes. I got it. I could see that.
I think it is (logically) better now, except the bug of ClientSizeWithBar you just found it.


Thanks you very much. I need go home now, see you again soon.


Regards,
x2nie

[Martin_fr]

And http://bugs.freepascal.org/view.php?id=26084

[zeljko]

And http://bugs.freepascal.org/view.php?id=26084

Which is fixed in the meantime

[x2nie]

... if any one is going to work on the GUI part of the IDE then you must keep in mind that the current layout is awful in windows 8 default theme. It requires a tone more space than on win7, they wend and raised the border size from the classic 2 pixels on each side


...to around 10 pixel-width on each side that makes the floating window layout a waste of space, ...

Yes, the prior taazz's screenshoot talks show the fact.
From that, I have a conclusion: The scrollbox (of component-palette) is a victim from the difference of Tform's border width dictated by different OS.
In other word, Lazarus IDE has wrong aesthetic calculation of Main IDE's form.Height.
This way, the Height of form is fixed; the border width of form is unpredictable; this affect ot scrollbox's Height of being the residue of available space.
pseudo : Scrollbox.Height = Form.Height - MenuBar.Height - (BorderWidth * 2 {topBorder+bottomBorder}).
Meaning Scrollbox's Height is affected by borderwidth, twice !
Meaning Lazarus has different ComponentPalette's Height between XP and Win 8. Possibly different in other theme or OS.


So far, its not a big problem in any OS, any Theme, any Widgetset,
It was proofed by such Taazz experience in Windows 8 which has the most biggest borderwidth, and component buttons is in good visual appearance.
But, while my current concern is the aesthetic perspective start from my own experience with Windows XP & Windows 7.
It looked like ugly to have extra margin in the bottom side of scrollbox; due XP takes only 2 pixel while Win 8 takes 10 pixel for each side of form border.


----------


Today, it seem easier to identify what is going on and what is expected as solution.
1. Component palette should be fine when implemented in any widgetset
2. CP should be fine in any theme (including Windows 8 default theme, plus 10pixel borderwidth of main IDE form)
3. (and it is my concern) component palette should vertically centered by providing balanced margin on top and it's bottom


IMHO, it will be done in several solutions / ideas.
1. We don't need to worry about widgetset; Because the different implementation is in the TPageControl, not in TScrollBox.
    We have no problem about TPageControl of ComponentPalette, so we leave it as is.
    But we will continue enhance the aesthetic in TScrollBox which is it has identical implementation in all widgetset.
2. When the active OS's theme changes the entire ClientHeight of the IDE mainform, additional border width will reduces scrollbox.Height,
    so maybe, it is the best time to make sure the scrollbox is in still good condition
    by correcting / recalculate the constrains MaxHeight of the form.
    Example: current lazarus's component palette is good enough in Win 8, but what will happen if other theme has more than 12 pixel borderwidth?
    We must able to avoid the ScrollBox to be too small.
  But it was done in current Lazarus, by providing extra space solution that will be used in such Taazz's screenshot.
  The only small bug is in the aesthetic /visual perspective. It need small adjustment, IMO.


3. The big mistake about Top Alignment of component-buttons is thinking that their Align is alTop. No, it's wrong. Nor: Align = alLeft !
    When we look at codes, all buttons are manually positioned by button.SETBOUND(x, y, button.width, button.height)
    Meaning that we have a chance to positioning button in anywhere we want, including to put it vertically centered within the scrollbox.


----------


Anyway, about additional idea such chevron, super-combobox showing all component in multi line in popup container,
accordion and so on, is in different expectation IMHO.
My current focus is about the current Component Palette located in MainForm, by the reason of it is always visible.
Every time we start Lazarus, we see it (component palette) which is in my eyes need "final touch" in it's layout design.
So it is the highest priority before providing extra features which are not shown in IDE main form.


Indeed, we can continue discussing that idea; but let me proof that my first idea will be fine, as it was expected.


Today, it is clear that making the buttons in vertical centered inside the scrollbox would not mess the widgetset implementation;
because there is nothing to ask widgetset about the bounds (left, top, width?, height?). All done manually hardcoded.

[Martin_fr]

Code: [Select]

component palette should vertically centered by providing balanced margin on top and it's bottom
If that is possible, then it should also be possible to adjust the form height (auto size) for each OS/Version. With the correct form height  there would be no need to add a margin for making it centred.

As I said, I remember being told that there is/was a bug preventing this. Not sure who knows the answer.


Currently Having no top margin has a big advantaged:
- When wrapping, I can see the top of the 2nd line. Adding another indicator that there are more items (the scrollbar is very tiny, and easily overlooked)
- Yet true, one can see, that this half visible line is even more ugly. And that it should always scroll to full lines, and show exactly one full line only.

One could also argue that v-centering the components, will look akward, as the toolbars (load/save/run button) are all top aligned.) This will especially be the case, if the required margin for centering is bigger. See my mock-up, I find this very unbalanced.
So "good looking" is subjective too.

------------
Anyway, I will not object to it, if any other team member wants to add your patch to center them to the IDE.

I am not sure, if all developers read here. They definitely are on the mail list.

------------
I will be happy to discuss and help getting a patch into SVN that will keep the "selection cursor" item visible, if lines are scrolled.

But the current approach (adjusting top in OnPaint is wrong)

At the time of any event from the scrollbox it is to late to update the top coordinate.

E.g. on Win32 ScrollBox uses the WinApi call "ScrollWindow" which acts immediately. So the scroll will be visible on the screen, before you can change the top coordinate.

On fast computers that may not be noticeable. But on slower PC that will flicker. (There is also a bug, that may currently prevent or reduce flicker, but once that gets fixed ...)

So the best way is to move the item out of the scrollbox, and Add OnClick events to all buttons, simulating correct up/down behaviour.

Otherwise you need to implement a scrollbox for which you can control when and how scrolling happens. That will be more work.

Feel free to discuss that, if/before you want to to anything on it.

[x2nie]

Code: [Select]

component palette should vertically centered by providing balanced margin on top and it's bottomOne could also argue that v-centering the components, will look akward, as the toolbars (load/save/run button) are all top aligned.) This will especially be the case, if the required margin for centering is bigger. See my mock-up, I find this very unbalanced.So "good looking" is subjective too.------------Anyway, I will not object to it, if any other team member wants to add your patch to center them to the IDE.

The art is subjective and doesn't require any logic for being exist. This one is very subjective.
But anything in aesthetic world is measurable. Margin is measurable, being centered is measurable.
Aesthetic is about why, art is about how.
Aesthetic is about function while Art is it's fashion.
http://en.wikipedia.org/wiki/Aesthetic#Aesthetics_and_the_philosophy_of_art




The weird thing IMHO is to judge: in where area the DESIGN can be found? is design = aesthetic or it is an art?
Meaning if we escalate the problems, we met big pain.
So, let we solve all task case by case. One by one. Don't let all good plan aborted by contesting problem each other.


I don't say that you did it, but I notice you that we might going to that.


------------


The Run button, Save, Save All, Stop, Pause, Open... etc. Button are top aligned; and it yield extra space in it's bottom side,
which is seem also ugly in my eyes. But this buttons are inside TToolbar, not in TScrollBox (like component buttons).
We can no nothing to positioning the Toolbar's button. But we can set bound the component button.


I think, the toolbars is already multiline (2 rows of toolbar in IDE), so for additional empty area in the bottom of toolbars, will always be easy recognized as extra space because the toolbar is top align.
While in the component palette: it seem expected as always single line, plus the buttons is "seem" as left aligned, meaning extra space should be in right side, not bottom side.


Same cases:
http://bugs.freepascal.org/view.php?id=24118
http://www.turbog.com/wp-content/uploads/2013/04/haiku_lazarus.png
http://4.bp.blogspot.com/-9iIXo5X4LEw/UVjWGwWUI5I/AAAAAAAAAbY/TmmtdiY3tZ4/s1600/Captura+de+tela+-+31-03-2013+-+21:34:01.png
http://blog.marcelofernandez.info/wp-content/uploads/2010/06/Lazarus_IDE_GTK1_Linux.png
http://2.bp.blogspot.com/-iw5SwXZwBEc/UYpCNenH6wI/AAAAAAAAAtM/DWoKFkhhrkA/s1600/Lazarus-running-on-Ubuntu-1.gif




Meaning the component-buttons seem as need "final touch" which is cleaning up the wrong area ( = make them centered vertically).
And toolbars are : seem well designed already; otherwise, we need to rethinking about how to center-aligning the toolbar?
Maybe the perfect as you are expect would to get rid from toolbar at all. We can reposition all (Run, Save, Open,..) button (distributed vertically) as what has done with component buttons (Menu, Button, Edit, Label, ...), by manually call SETBOUND


--------------
I disagree:

...
On fast computers that may not be noticeable. But on slower PC that will flicker. (There is also a bug, that may currently prevent or reduce flicker, but once that gets fixed ...)

So the best way is to move the item out of the scrollbox, and Add OnClick events to all buttons, simulating correct up/down behaviour.

Otherwise you need to implement a scrollbox for which you can control when and how scrolling happens. That will be more work.

We must avoid flicker by look at the detail. At least, flicker is under tolerance when not occurs repeatedly.




Again, move the arrow button outside the scrollbox whould excalate the problem. The selection of component button is not only used inside one unit.PAS, there are several units accessing of which button being down.
Another reason is there are no such OnClick. instead there are OnMouseDown, OnMouseUp, OnDblCLick.
And it is going to more complex while hacking the behavior of the buttons : when knowing there is Multi-Select mode when user Shift+Click on one of component-buttons.


----------------


However, when LCL could adjust client are by setting such BorderWidth = 5, it would solve both toolbar + scrollbar's aesthetic bug.
But it seem will never happen due LCL kept compatibility with Delphi behavior.


So, we need to look for other solution.


What do you think ?

[x2nie]

Hi guys,
About multi-row implemenation of Component Palette, what's your oppinion about CodeLite ?
http://hative.com/wp-content/uploads/2013/10/free-ides/free-ide-codelite-6.jpg