Forums Feature Suggestions Docking Dialogs

Yes, I'm aware that there have been many posts on dialog docking before, however, I have come up with another way to do it, and figured I may as well suggest it in a new thread.


We currently have options for dialogs (such as dbu, notheme, etc), so I figured why not have an option for the dialog to become dockable.

ie:

option dbu dock

Then, when running the dialog, a switch could be set to specify where the dialog would dock to.

eg:

/dialog -mp <position> <name> <table> <text>

In this instance, the [x y w h] paramters are not needed (as it is specified in a position)

These are the following positions:

top
bottom
right
left
nicklist


The docked dialog would then be draggable to any other part of the mIRC window.

quote: The docked dialog would then be draggable to any other part of the mIRC window.

i think that misses the point of a docked dialog

yer, docked dialogs are supposed to stay where theyre docked :tongue:

Actually, being able to drag and dock it where you want would be nice. A lot of software has this ability.

actually i dont thing that a docked dialog opened to stay a certain place should be moved. thats just my opinion. if i wanted to move it then i wouldnt have docked it, now would i?

exactly, a movable docked dialog wouldnt be a docked dialog, it would just be the same as it was before docking it .

lol .. I think you guys need to look up the word dock.

Here is one definition:
To maneuver (a vessel or vehicle) into or next to a dock.

Here is another:
To move or come into a dock.

Nowhere in any definition for dock does it say it can't be moved to another dock.

And then there is stationary:
a. Not moving.
b. Not capable of being moved; fixed.

so dockable dialog and stationary dialog would be two different things no?

Reply to _D3m0n_
So currently, all that is available is floating dialog.
All three options would be nice with floating being the default option IMO. So if you do not wish to use this option, you're not required to.

Option:
1: The act of choosing; choice.
2: The power or freedom to choose..
End reply to _D3m0n_

i think you knew what we meant :tongue:.

really? so u think that docked means movable? or not fixed position? well if you dont dock a dialog using a dll in mirc currently your able to move it anywhere...... u can remove the titlebar and have it appear without them just as if it was docked..... now that being said ..... there is NO need to EVER add anything else to mirc using your way of thinking..... because mirc already has movable dialogs.

i think u need to really rethink your statements before u post them, instead of jumpin my statements. im pretty damn sure currently the way mirc is there is no need to add anything like a docked dialog thats movable. now please tell me your not completely ignorant and are gonna argue that?

hes being ignorant because you proved his idea has no uses.

actually its not his idea its neophytes idea .. which really is a good idea, it just needs to be thought out differently. maybe saying all dialogs should have the drag and drop grips to them to look more like the other dialogs in mirc would be the best way to support this idea..... not even docking them at all... just by adding that to it it would then function like the other programs mentioned above. i am not saying the idea is wrong, only the method of accomplishing it.

see the above post, im not saying i dont have use for it. only that the method of accomplishing it should be different. actually it is a very nice idea. altho i do not support the idea of docking it and then being able to move it after? that has absolutly no use to me once its docked it should stay there and not be able to be moved at all. i like the way ktools docks things and makes them stay there. thats how i would want this dock function to work as well.

No it doesn't. Are you saying that the makers of Winamp, Windows, Trillian, AIM and countless other programs are all "missing the point" of dockable windows/toolbars because they allow you to undock them?

Simple solution: add a second switch, or a parameter of the current switch to chose whether ot not the dialog would be undockable.

collective the current nicklist in mirc is docked..... it doesnt move unless u do it thru the options... now the current dialog scheme in mirc all dialogs are moveable.. just by grabbing a corner and moving it. now suggesting a dock function be added that doesnt truly change anything in mirc dialogs is a useless idea. for a couple of reasons.

what would this feature add that cannot already be done? answer nothing. since u can already move any dialog in mirc already anywhere u want it. dockin should be added yes. but in a different method than suggested

as for the other programs u listed. thos dialogs are not stationary either. they operate just as any dialog in mirc already does currently. u grab the side and drag it where u want it. let go and it stay there. thats not a FIXED position dialog. now i dont know what u consider docked, and i cannot argue what docked is in your mind.But to me what was suggested above is useless because its already accomplishable without even adding one dll.nor does it need to be scripted. i do however support a docked feature similar to how ktools docks dialogs. and actually id like to have a docking feature which had all dialogs have the grips as in the 6.1. having each section of it able to move. That would be the best way in my opinion to change how all the dialogs work. i would love to take the nicklist and move it where i want it. the toolbar and put it where i want it.and things like that. if this is the way mirc is heading im all for those additions. i was glad to see the grips on the switchbar and the toolbar, but disapointed the toolbar one didnt even work.

Of course you can already move dialogs in mIRC whatever you want them, but since when could you drag them to the side of the window and have them stick there, as a docked dialog works with ktools.dll, and as windows docked to eachother do in winamp? You can't, atleast not without the use of DLLs.

As r0ck0 said, a better way to put it would be "being able to snap it to a docked position". Personally I thought it was obvious that that was what the orignal poster meant, or atleast that he meant they would be undockable.

I think a dialog that is "docked" to something else means that when that something else is moved, the docked dialog moves with it. That is exactly what ktools.dll does, as does winamp. When the desktop is resized docked AIM windows, trillian windows and Windows toolbars move to the side of the desktop they were docked to, undocked ones stay where they were.

I believe what he means is something like the switchbar. Where you can move it to dock it to a different side of the screen.

yes .. perfect example .. wish I would've thought of that before.
So good examples would be:

menubar & toolbar = stationary
options dialog = floating
switchbar = docked

and i also said that would be the way id like to see it as well ... using them grips, actually id prefer every window to be some type of that method. As really that would be the way to do every dialog not just a select few.

Another example is like the C# compiler, VC++6, even word... You can "drag" the icon-toolbar dialogs to the position you wish to have it. A docket dialog, as was already said, does not mean to attack it to a fixed position. it simply means position it in a certain area.. By this, we mean general area, not exact x,y location.

Why have it for every dialog? Docking doesn't make sense for most dialogs.

If i dock a dialog in my script, then the reason for that is that i want the dialog to be there.. and if you can move the dialog around the screen, then why dock it at all? a person working with a DLL to make hes/her dialog dock in a place on the screen, then all you have to do to move it is to drag it around the screen.. not what i should want to happen with my work, if it dont appear on the place i want it to be, then i wouldent make it dockable

Because they might want to make it so that the dialog can be attached (docked) to other dialogs and will then move/resize with that other dialog, or because they want the dialog to be able to be docked to the interface at the users discretion (like the switchbar).

Well the thing is a dockable window isn't supposed to be where "you" want it, it is supposed to be where the user wants it. If the user likes it on the right of the screen instead of the left, that should be the user's choice, not the programmer's.

then you make it so he can set where he wants it.. ike the bar in mirc.. "the one with status", shouldent look so great to be able to put that in the middle of the screen

Ok. I obviously haven't done a very good job of explaining the concept of docking dialogs.

Yes, there are certain cases where one might want to dock a dialog.

For instance, if you've created a toolbar for channels that is (in a sense) a re-creation of the channel central dialog.

Such as this: http://www.atomicscript.com/toolbar.png

Or perhaps you've created a nice little "ops" dialog which has a list of buttons and so forth on it that give you quick commands to kick/ban/whois people etc.

So there are cases where a dialog could be docked.
Granted, not always the case. But I do believe that there are some uses for docking dialogs.



Secondly, the whole idea of a moveable docked dialog, is simply this (as some others have explained).

Say the developer docks the dialog to the top (underneath the switchbar), and the user doesn't like it sitting there, well, as with the switchbar, it is "moveable" to a new docked position, say, the bottom, or the left/right of the screen. The dialog is also moveable onto the screen to become a floating palette (in a similar manner to how MS Office has floating and dockable shortcut bars).

Does this satisfy some of the questions here?

Oh, yes, the idea does need a bit more thinking out, however, I was just "sketching" the idea out for everyone to see.


*EDIT* Fixed url

*ADDENDUM*
I forgot to point out in the original thread one small thing:

The /dialog -mp command would be this:
The -m is for modeless (obviously), whilst -p is for positional (aka dockable and drag-dockable).

I don't know if you were just making a general reply and happened to click my name or whether you thought I was disagreeing with you. I wasn't.
I was replying to what D3m0n said: 'actually id prefer every window to be some type of that method. As really that would be the way to do every dialog not just a select few.'.

I did think you were commenting about mine, but bleh.

It was also a general reply.

Dammit, why can't we just have a simple "Add reply" that doesn't require re'ing someone!

In this case I'd probably reply to myself.
I like the suggestion, I'd use it.

Click & hold the switchbar, and you can move it around. But it's still a docked window/dialog/form.