Hi,

until a few revisions ago, the dropdown list of files which is shown right-clicking on the editor tabs, would show an asterisk beside modified files, which now has disappeared, at least in Linux.

This was very useful, because one could quickly return to the file under editing, after verifying declarations, etc. in other files, even with many open files.

Could this feature be reactivated?

Thanks,

Giuliano

If the above is correct, then a +1 from me, because the * is something I rely on...

Michael.

<michael.va... wrote

If the above is correct, then a +1 from me, because the * is something I rely on...

The * has now been replaced by the more popular ' ' (space) character. ;-)

PS;
What about colour coding the tabs. A modified file makes the tab a different colour. EditPad Pro does this very nicely.

Not all ws supports changing tab color. Maybe all supports tab font changes ...

zeljko

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

2012/3/19 zeljko :

Not all ws supports changing tab color. Maybe all supports tab font changes

I think that the * is better then font changing. For me it clearly identifies with changes while a font change could mean anything.

+1 in any case.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120319/35290f41/attachment.html>

2012/3/19 zeljko :

Not all ws supports changing tab color. Maybe all supports tab font changes

I thought the tab control used in the editor was a custom drawn control? [so popup menus, x close button per tab, tab alignment etc. could be available in all platforms]

Felipe Monteiro de Carvalho wrote

I think that the * is better then font changing. For me it clearly identifies with changes while a font change could mean anything.

Yeah, I wouldn't like the font changing idea either.

No, SE tab control is native handle.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120319/88b69250/attachment.html>

This is not the case:

[so popup menus, x close button per tab, tab alignment etc. could be available in all platforms]

So this is not true either:

the editor was a custom drawn control?

;)

Regards,
Sven

zeljko <zeljko at ... wrote

No, SE tab control is native handle.

Umm, who made that clever decision! I don't think I know of a single IDE (except now for Lazarus IDE) that uses a native tab control in the IDE editor screen. IDE's need more visual functionality than standard "native" controls can supply - for that reason most if not all IDE's use custom controls all over the IDE interface. eg: Delphi uses non-native tab controls, treeviews etc. So does Qt's IDE, Java IDE's etc.

Op 19 maart 2012 15:09 heeft Graeme Geldenhuys
het volgende geschreven:

Indeed, so clever, that -until you were told- you didn't notice the fact that the Lazarus developers didn't spend their time on creating their own tab control. :-)

A smart decision indeed.

Vincent

Graeme Geldenhuys wrote

Umm, who made that clever decision!

Until some months ago there was no custom drawn TCDPageControl in the LCL, so there was no decision to be made.

Vincent Snijders wrote

Indeed, so clever, that -until you were told- you didn't notice the fact that the Lazarus developers didn't spend their time on creating their own tab control. :-)

That is incorrect, I wrote TCDPageControl which is part of the LCL:

http://wiki.lazarus.freepascal.org/Lazarus_Custom_Drawn_Controls#TCDPageControl

Without it, it would not be possible to correctly implement FPBrowser with the LCL:

http://wiki.lazarus.freepascal.org/fpbrowser

IMO Delphi and all other platform-specific applications and IDEs use native controls. In so far the Lazarus IDE is different, because it claims to be platform independent by use of the platform independent LCL components. Where it should be known that most LCL controls have platform or widgetset specific restrictions...

DoDi

I see the asterisk in revision 36166.

Mattias

Sorry. I looked wrong.
I added the asterisk.

Mattias

Felipe Monteiro de Carvalho ha scritto:

OT, but not that much.
About CD components.
I was musing on the need to implement CD OpenFile/OpenDirectory dialogs. Could we take advantage of VirtualTreeView?
Giuliano

Mattias Gaertner ha scritto:

Thanks,

Giuliano

Giuliano Colla wrote

I was musing on the need to implement CD OpenFile/OpenDirectory dialogs.

My plan is to have various dialog options:

1->Generic open/save/sel dir dialogs for mobile applications in the unit lazdialogs.pas (those are finished from what I remember). That would be utilized in Windows CE.
2->Native dialogs for Android, iPhone, Windows and Mac OS X 3->Generic open/save/sel dir dialogs for desktop applications in the unit lazdialogs.pas (not yet written). That would be utilized in X11 which has no native dialogs

Could we take advantage of VirtualTreeView?

No, because:

1->The codebase of Virtual* controls is a huge mess. They are not fit for inclusion in the CD controls which are very clean and compact 2->AFAIK we don't need TCDTreeView. TTreeView is custom drawn by design in the LCL =) It would be like writting TCDImage. It makes no sense because TImage already works automagically without any extra effort in LCL-CustomDrawn because it is TCustomControl based. I haven't yet tested to see if TTreeView works or what is missing.

The hardest controls missing are TCDListView, TCDStringGrid and Menus.

Vincent Snijders <vincent.snijders at ... wrote

Indeed, so clever, that -until you were told- you didn't notice the fact that the Lazarus developers didn't spend their time on creating their own tab control. :-)

You are not paying attention, dear Vincent. Some core Lazarus developers have created custom controls. The LCL CustomControls should be a drop-in replacement, should it not?? The IDE already uses some custom IDE controls, so why would a few more be so wrong?

Using such custom controls should hopefully also stop developers like myself hacking the LCL backend widgetsets to get features in the IDE - because the all mighty "native API" doesn't support it. Long before the IDE allowed you to set tab alignment for the source editor, I hacked the LCL-GTK2 widgetset to give me right-aligned tabs.

A smart decision indeed.

-1

Felipe Monteiro de Carvalho <felipemonteiro.carvalho at ... wrote

Until some months ago there was no custom drawn TCDPageControl in the LCL, so there was no decision to be made.

Fair enough.

That is incorrect, I wrote TCDPageControl which is part of the LCL:

:-)

Op 20 maart 2012 07:36 heeft Graeme Geldenhuys
het volgende geschreven:

Resources. Rather have 1.0 this year (could have been last year if more developers were more focused), than a shiny IDE with the relatively newly developed customdrawn tabcontrol and 1.0 next year.

> A smart decision indeed. -1

I guess we agree to disagree.

VIncent

Graeme Geldenhuys wrote

The LCL CustomControls should be a drop-in replacement, should it not?? The IDE already uses some custom IDE controls, so why would a few more be so wrong?

Every case should be discussed separately, but in general I would not change anything which already works before 1.0

Vincent Snijders wrote

Resources. Rather have 1.0 this year (could have been last year if

I didn't know 1.0 is that close...

[humour]
Then again, saying "Lazarus 1.0 will be out this year/soon" should be held in the same light as the other popular saying: "This year will be the year of the Linux desktop" (which is said religiously every year, yet never materialises). ;-)
[/humour]

Felipe Monteiro de Carvalho <felipemonteiro.carvalho at .... wrote

Every case should be discussed separately, but in general I would not change anything which already works before 1.0

I understand your intentions, but that is a odd statement none the less. Lots are being changes in Lazarus as we speak (before 1.0). Lots are being fixed, and lots are being broken. Development in the Lazarus project now, doesn't seem any different to any other time in its history - just read the mailing list to see what I mean.

Anyway, I respect the decision to not change the tab control in the editor window at this time.

At least in newer Delphi versions (2005+) the source editor tabs seem to be a custom one as I can't find other applications with such a tab style.

Regards,
Sven

Hans-Peter Diettrich wrote

IMO Delphi and all other platform-specific applications and IDEs use native controls.

Wishful thinking - they don't! In the case of Delphi, they use VirtualTreeView all over the place (a custom draw component as you should know). The editor tabs are custom controls, and so are many other areas of the Delphi IDE (component palette etc). Use any Windows "window query" tool to query the Delphi IDE interface and see what I mean (a simple tool like MWSnap's Window Info function should do, but there are many others you can use too).

In our previous episode, Graeme Geldenhuys said:

> IMO Delphi and all other platform-specific applications and IDEs use native > controls. Wishful thinking - they don't!

They usually do, but not always :-)

Moreover, you have a choice to do so in cases where it is important to use the less optimal one over the ownerdrawn one. (e.g. to achieve maximal RDP speed)