I did some testing with the new sparta docked form designer on OSX. here is a video clip of it in action:

http://cache.getlazarus.org/video/docked-design.mp4 -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151123/14a5c2eb/attachment.html>

2015-11-23 11:40 GMT+01:00 Anthony Walter :

I watched in suspense :P. Thanks for testing :)

Maciej Izak wrote

I watched in suspense :P. Thanks for testing :)

Maciej, creating a component's default action by double-clicking also works now, but deleting a component from designer still does not. Deleting from OI works. Can you reproduce it? Do you know what has caused it?

Tested on Linux with GTK2 and QT bindings.

Juha

Anthony Walter wrote

I did some testing with the new sparta docked form designer on OSX. here is a video clip of it in action:

May I make a suggestion. Why not automatically place non-visual components (eg: TOpenDialog, TSaveDialog etc) in a dedicated non-visual area outside the designed form: eg: in a panel above the "Code, Designer" tabs shown in the video. It could even be order alphabetically.

I never understood why non-visual components lived inside the designer form at a specific x,y position - cluttering up your designer form. Even the streaming had to be "hacked" to support a fake x,y position for these non-visual components.

Regards,
- Graeme -

Juha Manninen wrote

works now, but deleting a component from designer still does not. Deleting from OI works.

I had the same issue in CodeTyphon if I remember correctly. Seems everybody copied the same broken code from somewhere. ;-)

Regards,
- Graeme -

Am 23.11.2015 12:35 schrieb "Graeme Geldenhuys" <

: On 2015-11-23 10:40, Anthony Walter wrote: > I did some testing with the new sparta docked form designer on OSX.

here is

I agree with Graeme. At least as an option :)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151123/9b9d5a61/attachment.html>

Nonvisual Components on some other place, where you could order them nicely by relation to each outer (DataSet <-> DataSource) etc... And maybe even some automation on this would be very nice indeed...

-Tee-

On Mon, Nov 23, 2015 at 1:35 PM, Graeme Geldenhuys <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151123/bc6023fc/attachment.html>

2015-11-23 12:28 GMT+01:00 Juha Manninen :

It is caused by not detected "Active Designer". I know where to start to fix that. Partially fixed in r50419/r50113 (for copy/paste operations).

2015-11-23 12:35 GMT+01:00 Graeme Geldenhuys
:

New "Non-visual" page (or some additional space in "Designer" page) for that purpose is planned in future. Please create on mantis "Feature request" for that.

Anyway sorting/disabling non-visual components is supported by FreeSparta solution:
https://www.youtube.com/watch?v=6FOjWCLDScQ&t=615

It should be ported very soon.

2015-11-23 12:36 GMT+01:00 Graeme Geldenhuys
:

I had the same issue in CodeTyphon if I remember correctly. Seems everybody copied the same broken code from somewhere. ;-)

Not related. The problem exist inside Lazarus IDE. Sparta is not copied from Typhon, rather Typhon is copying patches/bug fixes from FreeSparta Lazarus branch.

2015-11-23 12:45 GMT+01:00 Sven Barth :

I agree with Graeme. At least as an option :)

My work on FreePascal compiler must wait a little again... -,-

The reason is simple: there was/is no other place where to put them.

I agree with Graeme. At least as an option :)

Not so fast. This is a can of worms you maybe don't want to open:

I don't use the docked designer. I most likely never will.

So if someone using the docked form designer has put the non-visual components outside the docked form, and I then subsequently open this form, what will happen ? Where will you put it ?

In yet another window ? I hope not.
In the component tree ? I don't use that, it is hidden.

There are always more angles to a problem than you may have considered.

Michael.

2015-11-23 14:06 GMT+01:00 Michael Van Canneyt :

It will not affect you. DockedFormEditor is just an option. All is backward compatible. Even new page "non-visual" will be only smart addition. In the worst scenario XY position of 'non-visible' component will just out of scope of form rect (unlikely).

Michael Van Canneyt wrote

The reason is simple: there was/is no other place where to put them.

Up to now, yes that is true. But then again a "designer form" could, and does, have behaviour different to that same form at runtime.

I don't use the docked designer. I most likely never will.

Neither would I. :) My suggestion was simply a suggestion on what I think is an improvement over the existing behaviour [personal opinion obviously].

Opening that project in a non-docked designer, it could always arrange the non-visual components along the bottom, sides, along all edges etc. Many desktop environments in the past and present have such behaviour with icons, so I see no harm in applying them for non-docked form designers too. You could even go as far as making the icon arrangement user selectable - again, just like past and present desktop environments allow.

There are always more angles to a problem than you may have considered.

The "docked form designer" is supposed to be an enhancement over the old one [opinions my differ] - my suggestion was just an extension of that enhancement. As with everything in Lazarus - making features option is ideal. ;-)

Regards,
- Graeme -

+1 for making a special area for non visual components when the docked designer is being used.

For those that doesn't want to use the docked designer hiding non visual components will not affect you they would appear normally. It's just that docker designer users will see the non visual components differently (in a separate tray along the bottom of the design window for example). -------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151123/f4a02c40/attachment-0001.html>

I eagerly await your demonstration of this fact :-)

Michael.

Define 'normally' as you will not have placed them 'normally' to begin with ?

Some kind of 'arrange non-visual components' popup menu will be in order, I suppose...

We'll see, I am curious.

Mchael.

In this regard:

Mattias Gaertner demonstrated the new 'Project Groups' feature during the Dutch Lazarus conference. It is implemented as a package (already in SVN under "components"), so it is optional.

As noticed by one of the audience, it is implemented better than Delphi Project Groups, (nested project groups, ability to add single files, build modes nicely integrated) even though there is still a todo list for them.

My own first impressions are already very encouraging :-)

Michael.

Michael Van Canneyt wrote

It is implemented as a package (already in SVN under "components"), so it is optional.

Oh, I didn't know it is already in trunk.... then again, I haven't updated my Lazarus for some time. I'll get an update now - project groups have been on my wishlist for years. :)

Regards,
- Graeme -

Micheal, I'm thinking they mean just a visual representation of the non-visual components, by having them displayed in a different area. For you, they would show up wherever you want to put them (by default the designer could put them in a grid), but the XY won't change of the components themselves, just putting them out of the way for the ones that want the option on (if I got it correctly).

- Dennis

"Den" wrote

Micheal, I'm thinking they mean just a visual representation of the

non-visual components, by having them displayed in a different area. For you, they would show up wherever you want to put them (by default the designer could put them in a grid), but the XY won't change of the components themselves, just putting them out of the way for the ones that want the option on (if I got it correctly).

What about newly added non-visual components though? Would they all just clutter in one spot?

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151123/ce9b5f94/attachment.html>

That is exactly what I meant with my remark...

Michael.

I know, but others don't seem to get the problem...

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151124/a3518ffb/attachment.html>

To those worried about components being cluttered on top of each other, do you really think it would be that difficult to address?

All the docked designer implementation needs to do is assign a position (Left,Top) to new non-visual components (NVC), that is those added while in docked designed mode. If there is an existing NVC nearby it just picks the next available (Left,Top) in a grid for the new NVC. It's not that difficult.

EG. repeat in an arbitrarily sized grid pattern ...

Is there a NVC between 0,0 and 48,48? Yes?
Is there a NVC between 48,0 and 96,48? Yes.
Is there a NVC between 0,48 and 48,96? No?

Okay then put the NVC at Left: 0; Top:48. Problem solved.

Next time a non docked designer using team member opens the project, they'll see a new component placed at 0,48. They can move it if they want. If the docked designer using team member goes back to working on said shared project, the placement of the NVCs will not be affected, because to him the NVCs positions on the form are never modified unless he adds a new NVC. If a new NVC is added while in docked design mode, go back to EG. above.

Not that hard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20151124/d107d1a0/attachment.html>

Well, your argument needs refinement, of course. Such as:
- don't go outside form borders, meaning go to next column.
- maybe sort the NVCs prior to placement, so as to have some logic ? (on renaming this means re-order the grid)
- What if there are more NVCs than fit in your grid ?

No-one said it is hard.

But:

1. It needs to be addressed *before* you enable this 'NVC outside form' option. Usually this is where things go wrong.

2. I place my NVC at meaningful or logical positions, or positions which don't disturb from finding the controls underneath. The above is basically arbitrary placement, which is very uncomfortable and doesn't make for fast finding of components.

So please bear with me and allow me to be slightly skeptical: Not everyone thinks the docked form is the best thing since sliced bread, to put it mildly :-)

Michael.

Michael Van Canneyt wrote

- What if there are more NVCs than fit in your grid ?

Then you organise it as follows:

http://geldenhuys.co.uk/~graemeg/datamodule.png

:-D

Regards,
- Graeme -

I have actually seen such a module in design and production ! How anyone can work with that is a mystery to me... :-)

Michael.

Michael Van Canneyt wrote

2. I place my NVC at meaningful or logical positions, or positions which don't disturb from finding the controls underneath.

Just to be clear, I don't like the docked forms designer idea either (neither in Lazarus nor Delphi), but the above is also not ideal for everybody. In my Delphi days, I have often placed non-visual components as you described - then the form gets redesigned or new widgets added. Then I move the non-visual forms yet again. A tabbed form often has this problem.

Non-Visual components is just that... non-visual, and their placement shouldn't have any impact. Getting back to the question at hand about the classic forms designer... As I hinted before, the forms designer already has different behaviour to the same play
with that. There is no reason why the classic forms designer can't have a non-visual area attached - keeping the actual form design uncluttered. Lets think out of the box for a moment... :)

Some ideas:

1. A 800x600 form could have a 200px panel at the bottom which doesn't form part of the designed form's runtime size. So the designer form is 800x800 in size. The non-visual area could be painted differently, to clearly indicate this area. Visual widgets can't be dropped in that area.

2. A floating non-visual drop area window could snap to the sides of the designed form and say there. It could automatically snap to the bottom by default, and moves with the designer form, even if the designer from is resized. Similar to what WinAmp or XMMS music players did back in the day with there secondary windows.

3. A keyboard shortcut similar to F11 could be implemented that toggles the form designer to show the designed form, or the non-visual components. If the non-visual components are visible (could look similar to a DataModule), they could be aligned to a grid (icon view) layout, or placed by hand I guess.

These are just "thinking out of the box" ideas. I'm sure more creative minds could come up with other ideas too.

Bottom line is (for classic forms designer and docked one) - I never liked the fact that non-visual components cluttered the designer form. Just because Delphi did it since day one, doesn't mean Lazarus needs to follow suite. Other development environments handle this differently - maybe better, maybe worse. But while there is a redesign of the forms designer, maybe this is something that could finally be addressed too.

Just my 2? worth. ;-)

Regards,
- Graeme -

Michael Van Canneyt wrote

How anyone can work with that is a mystery to me... :-)

Manually finding something was impossible. Thank goodness Delphi's Object Inspector had a search function (if I remember correctly).

Regards,
- Graeme -

Graeme Geldenhuys wrote

Then you organise it as follows: http://geldenhuys.co.uk/~graemeg/datamodule.png

:)

Marcos Douglas

2015-11-24 10:31 GMT+02:00 Anthony Walter :

To those worried about components being cluttered on top of each other, do you really think it would be that difficult to address?

..or you can add a button "Show/Hide NVC"..