for many years, i've used editors that allow for more than one file to be open at once... in those editors, there's generally been an 'X' to close that (sub)window containing each additional file... some editors have an 'X' for all files and closing the last one results in a new blank page...

with today's tabbed environments coming out and being all the rage, the 'X' has been moved to the tab for each file...

so anyway, the other day i'm working in laz and had a need to have more than one file open at the same time... when i was finished with the other file, i went to close it... i couldn't find the 'X'... there was the "big" main one for closing the entire laz IDE (ALT-F4) but not one for the individual files' windows... it took me a minute or two before i realized that i could right-click in that window and choose "close file" or i could use CTRL-F4 (which i have used in the past but not on a general basis and less as i get older)...

so anyway, my question is "where's the 'X' for closing each individual files' window?"

2011/8/29 waldo kitty :

This feature is not implemented in the windows page control, it is in gtk2.

Vincent

Vincent Snijders wrote

2011/8/29 waldo kitty: >

[TRIM]

ahhh... i would have thought that it would be implemented everywhere :?

so i need to make a feature request somewhere? i don't think my widget-fu(?) is enough for me to locate where and do what is needed to be able to offer a patch :(

Vincent Snijders wrote

This feature is not implemented in the windows page control, it is in gtk2.

And from what I remember there is still a bug in the LCL's GTK2 version. If you did code navigation (Ctrl +Click), then click on the X in a tab, it closed all other tabs except for the one you clicked on. :-( That was a very annoying bug I trigger often.

The Ctrl key state was "sticky" for some reason. I reported this problem, but can't remember if it was ever fixed - i haven't tried trunk in ages. I have since been using Ctrl+F4 (close file) instead.

Also not showing the X in the tabs (LCL-GTK2), makes the tabs much smaller, so you can fit more in the source window without scrolling. This "larger tabs" issue is only in LCL-GTK2, not in plain GTK2 apps (eg: gedit, firefox etc).

The bug is still present in trunk. I stepped on it while looking at the AltGr support (regarding the SynEdit column-mode discussion for which a follow-up is still in my drafts :-$ ).
The LCL use a hook to peek into key messages and "caches" ShiftState, it's in my to-do to look at using gdk_event_get_state() or gdk_window_get_pointer() instead...

Best regards,
Fl?vio

> This feature is not implemented in the windows page control, it is in > gtk2. ahhh... i would have thought that it would be implemented everywhere :?

While the ComCtrls originate in Windows, the LCL based them on other widgetsets (mostly gtk), and left only rudimentary functionality in the Windows widgetset.

so i need to make a feature request somewhere? i don't think my widget-fu(?) is enough for me to locate where and do what is needed to be able to offer a patch :(

After a couple of tries, to make the Tab/PageControls work as in Delphi, I gave up offering patches for these controls. If I ever need Delphi compatible ComCtrls, I'll implement my own WinCtrls.

The only reasonable feature request were for a separation of really Delphi compatible controls (VCL), working at least in the Windows widgetset, and another (parallel) set of portable Lazarus controls, with different behaviour and features (something like CLX).

If you want to put your hands on the Win32 widgetset, supply an ownerdraw procedure for showing the 'X'. Then the gurus should be able to fix the hit test, so that the widget can react on an 'X' click, and can offer the tab menu from a right click on an tab. Both features are not supported yet.

DoDi

Afaik, quering always was an issue on gtk especially if used on remote display, as it is (so I was told) slow on some systems)

I do know, that there was some work done (as I was involved), that leads to updating the cache in mouse events (move up down, IIRC) => and on platforms that I tested this solved the sticky ctrl issue (including when focus was moved away from the app)

IMHO the original report was that ctrl was sticky when the app lost focus while ctrl was pressed. I do not know about the code navigation part, making ctrl sticky => first time I hear this => so I can't comment on this.
Also I have not lately tested any of this, so I can not comment if anything was re-introduced.

Vincent Snijders wrote

This feature is not implemented in the windows page control, it is in gtk2.

Qt have close buttons on tabs too.

zeljko

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

2011/8/31 zeljko :

I think the easiest implementation would be drawing/adding the button on tab hover, so it wouldn't affect the tab-button size. Would this be ok? (implemented on LCL-Win of course)

-Fl?vio

FWIW: i don't really care if it is on the tab or the frame... i rather prefer the frame, though... especially since i don't see any tabs on the individual open files in the editor...

FWIW2: so far, lazarus looks pretty much the same on both w2k and vista... quite unlike FF5 and FF6 which are worlds apart between the two OS'...

am i missing something? what tabs are visible when there are multiple files open in the lazarus editor? i can provide a screenshot of what i see if necessary...