Hyperion Entertainment Message Boards

First of all thanks a lot for the new shell, compile somethings is way better now, not to mention the long waited scrollbar finally !
I have a couple of request aniway, anytime i need to open (or close) a new shell i need to use the menu (or eventually the shortcuts)

It's ok of course, but personally i found this a bit unfriendly ... so how about adding a close gadget to the shell's tab and a "new shell" button in order to just use this button to open a new shell (or press a close gadget to close an existent tab) ?

To give you an example see how it was implemented in Origyn Web Browser, a close gadget into the tabs in order to close the current one, and a little button on the area at the right side for quickly opening a new instance

@Samo

I already make a BZ-improvement for it for about 1 year ago. The problem there, is that for making it only for shell, Tony need to make the same custom routines as for example Simon do in codebench, and it wasn't very easy/system-friendly if i remember right.

So, i made 2 BZ, one was about adding a possiblity to attach close gadget to system gadgets (i do not remember now, is it was about gadget.class or anything like that). After that will be done, Tony can use it for the shell as well.

Yes, it still possible to add custom-code as Simon do, but imho better firstly add necessary changes to relevant system component, then anyone can use it easy later. More system-friendly code the better.

I also sure that after you will play with shell more, you will think "why there is no dynamic list of opened shells generates in menu, but instead i need to use those NextSheel/PrevShell items", but for that i also make BZ year ago too, with idea how to restructure it to make it a bit more user-friendly and logical. Hope Tony will do it someday as well

@Roman

I already make a BZ-improvement for it for about 1 year ago

Ok good to know that some improvements were reported aswell, if you read my recent topic you will see that for now i have various problems with the final release but actually the shell is probably the main reason that prevent me to come back reinstalling the update 6

kas1e wrote:I already make a BZ-improvement for it for about 1 year ago. The problem there, is that for making it only for shell, Tony need to make the same custom routines as for example Simon do in codebench, and it wasn't very easy/system-friendly if i remember right.

So, i made 2 BZ, one was about adding a possiblity to attach close gadget to system gadgets (i do not remember now, is it was about gadget.class or anything like that). After that will be done, Tony can use it for the shell as well.

clicktab.gadget has had the ability to add a close gadget for a long time. As samir says, the original OWB (Joerg's version) used this, CodeBench uses it, NetSurf uses it. It's entirely integrated into the class, just needs to be added and a bit of extra code to check if it was clicked.

Should be easy, and will make the new shell a more pleasant experience.

It's not that easy. The application still has to produce its own imagery for ClickTab to display. That imagery then has to be scaled to suit the height of the ClickTab and font.

If you look at OWB (the only app I use that has it), you have to click twice to close the tab - once to get its attention, and a second time to tell it to close. The image is not displayed on inactive tabs.

If you already have its attention (it's the current tab), then you can:

1) (If your hands are on the keyboard) type RAmiga/K (close Shell);
2) (If your hands are on the keyboard) type Ctrl-\ (close Shell);
3) (If your hands are on the mouse) click the go-away box top LHS; or
4) (If your hands are on the mouse) select Close Shell from the menu.

With so many ways to do it, I don't see much to be gained by adding another few pages of code to do the same thing.

tonyw wrote:The image is not displayed on inactive tabs.

Yep, what you said was supported before, but then the behavoiur was changed starting from clicktab.gadget 53.39 (if i remember correctly the exact version)

See: http://os4depot.net/filedata/snapshot/6356_3_snap.jpg

If Rigo is the author of the class maybe we can ask him ?

tonyw wrote:It's not that easy. The application still has to produce its own imagery for ClickTab to display. That imagery then has to be scaled to suit the height of the ClickTab and font.

NewObject(NULL, "sysiclass", SYSIA_Which, CLOSEIMAGE, TAG_DONE);

If you look at OWB (the only app I use that has it), you have to click twice to close the tab - once to get its attention, and a second time to tell it to close. The image is not displayed on inactive tabs.

I don't know why that was changed.

If you already have its attention (it's the current tab), then you can:
[....]
3) (If your hands are on the mouse) click the go-away box top LHS; or

Shouldn't that close the entire window - ie. all tabs?

Having the close gadget on the tab, and then changing the window close gadget to close the window as expected, would be more intuitive.

@Chris
I dig in into bugzilla, and found my BZ (which i discuss with Simon before doing so), #8348. There is full text of BZ:

Title:

default image for close gadget and create a way to get that image without the titlebar gradient

Body:

Currently to make our tabs to have close gadget we have a tag to active it, but
gadget itself is limited: there is no default image (simply because one doesn't
exist in the system), so need to create one (and maybe the one from
codebench/codepad can be used already as system's default?) and that close
gadget which we have now , just rendered with the titlebar gradient behind when
called for by intuition, so it isn't much good in the clicktab. So we also need
to create a way to get that new image without the titlebar gradient as close
gadget. By that way, any programs like browsers, text-editors, tabbed viewers
and even our console can use it without creating of custom code for providing
different close-gadget images, and without worry about their sizes via
preferences or so. Pure 2 states (pressed/unpressed) are fine, but of course
better to have 3 states: unpressed, pressed and darken when mouse cursor over
it.

Sure, Tony still can deal with close gadget even without implementing that, just like in codebench/codepad (and netsurf i assume) , but imho better to made firstly system-friendly way which can handle all cases, and then Tony can add it to shell as well if will have time/interest for.

@Tony

With so many ways to do it, I don't see much to be gained by adding another few pages of code to do the same thing.

Do you mean "there is no needs to have close gadget in active tabs at all as you can use keyboard to close them ?":) . By the same logic, then no apps should have close gadgets, not text editors , not browsers, nothing. The purpose of having close gadget in the tabs (of any application, be it shell, text editor or whatever), is to have much better visuall feadback to user who operate with your app. User have no needs to know anything about other ways, he just visually see the there is close gadget which he can press and tab will be closed. If there any other ways to close tabs : good. But close gadget today is the first way in any decent app which have tabs (that on all OSes, and on amigaos4 too, like in codebench, codepad, owb/odyssey, timberwolf, annotate and whatever).

And in end it not only better for usability, it also have better look. I mean, close gadget in tabs are must Another story that is not you who should make all that custom code to handle all the states, but class should provide it (for what reason i made BZ year ago). But probably if you will want to implement close gadget in the shell, somebody will update relevant class in the os

I think the new shell is fine the way it is. Try this:

Open a shell from the icon and use the menu to open 3 more shell tabs. Minimize the window. Where are the close gadgets going to go to now.

If there are close gadgets in the tabs, the tab handle would need to be wider to accomodate the title and the close gadget. I think adding close gadgets would be more complicated than everyone thinks and I'd rather see time spent on bugfixing. In the case of the new shell, I say leave well enough alone.

xenic wrote:the tab handle would need to be wider to accomodate the title and the close gadget.

Well eventually tabs can be provided with a fixed dimention if the problem is that, in some case if a particular strings title are too long one can provide a classical "..." to trunk it at some point in order to make all tabs at the same dimensions and look, an help bubble to read the whole title (like NetSurf) can be provided too if needed .. what kas1e said is pure logic