Is there a reason, why the Lazarus IDE is using groupboxes with normal font as well as a combination of bevels and label with bold font for groupbox functionality?
For ex. IDE Options -> Environment vs. IDE Options -> Editor. It think this doesn't look consistent.
I vote for using TGroupBox with Font.Style:=[]; all over the place.

Regards
Theo

Groupboxes were cluttering the real info, therefore we made a change to the bevels. Not all parts are done.

Marc

Marc Weustink wrote

Groupboxes were cluttering the real info, therefore we made a change to the bevels. Not all parts are done.

Any objects in creating a custom component which does the dividing instead of using 100's of TBevel components and lots of advanced Align settings?

It should be very simple to knock together a simple divider component - custom drawn and only to be used in the IDE (not available on component palette).

This is what I meant before by creating custom drawn components, which are only meant to be used inside the IDE. A more versatile NoteBook component for the editor is another candidate.

PS:
I have to agree, the Bevel+2xLabel does look less cluttered that GroupBoxes. An alternative might also have been the Gnome HIG style. One bold label defining a section. Then the components for that section, but slightly indented. See attached screenshot for very quick mock-up.

Regards,
- Graeme -

Thanks!

There's one little thing I'd like to submit:
While real TGroupBox - Captions (at least on GTK2) are theme aware (bold, not bold), the labels on the bevels aren't. That's another reason why it looks strange now, if your system has non-bold TGroupBoxes.

System groupboxes may look very different depending on settings/theme.

See attachment: One taken on my OpenSuse 10.0, the other on OpenSuse 11.1. Using same GTK2-Lazarus-Version both.
See frame / no frame, bold / not bold font.

By introducing custom "groupbox-alikes", Lazarus is giving up a part of the system look.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gboxtest.png
Type: image/png
Size: 11902 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20090826/0f4e1256/attachment.png>

theo wrote

While real TGroupBox - Captions (at least on GTK2) are theme aware (bold, not bold), the labels on the bevels aren't.

Correct. In Gnome I have my text set to dark-blue color. The TLabel components in Lazarus do not seem to adhere to that theme color. See the attached screenshot I posted earlier. The issue is even it the Form Designer. The captions of TCheckBox is correct color, but TLable is not.

Then again, I am not sure if Lazarus IDE theme is that Section labels must be black color and bold. Hard-coded by design - if so, then I don't mind it.

Regards,
- Graeme -

Well, it's doing that already by using the Label & 2xBevel isn't it??

Yes, I counted these as "//groupbox-alikes" too in my prev. message.

I don't mind if you use custom components for the IDE if there is a good reason to do so. But you should be aware of the fact that they do not follow themes with the current solution.

As long as both (TGroupBox, custom groupbox) are used together, it may look inconsistent mainly because of different caption-font.

//

theo wrote

By introducing custom "groupbox-alikes", Lazarus is giving up a part of the system look.

Well, it's doing that already by using the Label & 2xBevel isn't it?? That's my point I was trying to make before. Custom components should be allowed, that are _only_ used in the IDE -- NOT in normal applications that must adhere to system theme/look.

IDE's are normally exceptions to normal applications because it is only used by a small target audience -- developers. Plus, IDE's need to convey a lot more settings and functions, which normal applications don't have to. You can have a look. Many IDE's use custom components that are only available in the IDE and not normally used in general applications.

Delphi 2007
* it's new component palette component with search/filter feature
* customized Virtual Treeview for many lists and trees

Eclipse
* non-standard tab control

etc...

Regards,
- Graeme -

Actually, I attempted to create a frame for this, but run into some bugs that prevented it.

I also thought about a custom component. The idea goes a step further. The component would also act as container for the items inside (like a panel). This can have several uses:
- depending on the availability off a layout manager, the custom component can do this. (like a groupbox, you just add the inner components)
- it can be used to help doing a keyword oriented search for *all* option-pages (each container searches the captions of all children)
- it may become collapsible (if no children matches the search) / not sure if really a good idea

IMHO not. I think the notebook is better solved by hiding the tabs, and using a listbox or even tree-view (sort by directory,...). What is the advantage of putting the drawing of such a list into the notebook itself?

Well a custom component (accommodating the other controls as children) could very easily switch between a variety of layouts.... (but I think that's not really needed)

2009/8/27 Martin :

Actually, I attempted to create a frame for this, but run into some bugs that prevented it.

And you didn't fix those bugs? ;-) Actually I never even though of using a TFrame - that could have worked as well.

- it may become collapsible

This was my second thought for a custom "grouping" component. For the more complex dialogs the grouping component would maybe collapse the more advanced (or less used) options by default.

IMHO not. I think the notebook is better solved by hiding the tabs, and using a listbox or even tree-view (sort by directory,...).

For GTK2, I hacked my copy of the editor notebook so that tabs appear on the right with horizontal text. Windows can position tabs too, but the text defaults to vertical which makes it much harder to read and does not save on space - which defeats the whole exercise.

To overcome the Windows tabs on right with vertical text issue, you need to do custom drawing to solve it. Hence my idea of a custom component for editor notebook. The other benefit will be that all widgets can be made to support the "x" close button on tabs. I have no idea how OS X looks with tabs on right or left edges - if it's even possible. Again a reason for custom drawn notebook component.

The idea of the listbox is actually a good one. There is already a nice Lazarus add-on which uses a listbox, supports drag-to-reorder and does filtering. I haven't had time to see if I can manually dock it inside the editor window. My copy of Lazarus already has two manually docked add-ons. The editor toolbar and the embedded messages window below the editor. So this makes it a bit more tricking docking the file listbox add-on.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Why would I do this myself? I delegated it. ;-> (that is to say I reported them)

Part of it is in fpc, so you need fpc trunc...

yes, that too

but a listbox will work on all OS.

true a list box does not have that (x button). but you could emulate the middle click, as it is used on tabs to close them.

But then this are 2 different things:
- custom draw tabs, to allow an [x] button (but keep orientation nativ) => IMHO this would make sense to add to the LCL for everyone.
- custom draw tabs, to change the orientation.
=> IMHO easier to use a listbox (better tree view), though it wont have the fancy border, and the [x] button was still left for solving

It could be fixed into the the source-editor window (meaning not un-dockable).
The source-notebook is probably alClient. so any extension can just add an alLeft (or alRight) component).