Nov 25, 2008 5:04 AM
SparkTabbedPane (Externalizing Tabs)
-
Like (0)
17501 Views
45 Replies
Latest reply:
Sep 29, 2010 10:59 AM by
wroot 
-
-
I want!
I just didnt notice your message before. How can i try your patch? I already has a svn copy and i can compile it with NetBeans. How can i apply your patch to this source code?As about history. Maybe it's worth splitting this functionalities? Personally i have never experienced history loss, but i know others are complaining often. And there is still two separate JIRA issues for tabs and history
-
-
I've found the way to apply your patch in Netbeans (didnt have a luck to run this project in Eclipse..). So i'm testing it now. Externalizing (hm, should be a better name for that) is working. The great thing is to see actual presence of a user in a taskbar window. I was asking for that for a tabbed window http://www.igniterealtime.org/issues/browse/
SPARK-935 . Probably i could close that issue if your changes will be submitted to a Spark release.Now issues and requests.
Maybe you can add an "Externalize" button to a tabbed chat window so one could easily move chat window to a stack and out of it.
When in a externalized mode chat window is not flashing in the taskbar upon message receiving. Also it jumps in the front, though i havent selected Bring to the front option.
As for a history. I see no difference. It still doesnt save the new message if i kill the Spark right after receiving it. On a normal exit it saves the history with the old source code and with your patch.
-
-
-
-
-
-
-
-
Niklas, everything is fine, in essene we were talking about the same. I agree with the current approach. Drag and drop is a nice thing to have too. Though, maybe this won't be very intuitive for novice users. I dont think additional button would harm anyone
We can try releasing this feature this way (without the additional Detach button) and wait for a feedback from the users.fgrsa, i can attach new compiled spark.jar a bit later (4-5 hours).
-
-
I was applying this patch to the 2008.11.15 trunk. Issues i've found:
* Message popups are now appearing, but the detached window is not flashing in the taskbar. I think it should.
* Also clicking on such message popup doesnt do anything in detached mode. Normally it brings the chat window in to the front.
* Another issue is that if i already has some user in a tab and this user sends me a message, then an additional detached chat window is opened. I think it should check if a chat is already open with that contact and just flash the already open chat widnow with a tab. This is happening because the option "Open new chats in separate windows" is turned on. But if a tab is already open, this should count as an old chat.
Drag and drop is a bit tricky. There is no visual effect while you are dragging the tab. So it takes some time to get used to it. You can only drag the tab out of the tabs stack when dragging upwards or downwards. Dragging to the sides doesnt do anything. Not a big problem. But i think we should definitely have a Detach button. Because attaching is done only with a button. Functionality should be the same for the detaching. And drag and drop could be just as a bonus option
History is indeed saving even after killing the Spark process.
Rodrigo, i'm attaching the newest patched spark.jar, but this is still for the testing purposes. It still has some little issues.
-
-
-
-
-
-
-
And about the naming. Daniel in http://www.igniterealtime.org/issues/browse/
SPARK-893 is suggesting Detaching and reattaching. This sounds better, imho. Externalize button - "Detach this tab to a separate window", Internalize button - "Reattach this window to a tab stack". Option in the preferences - "New chats open in the separate windows". Just a suggestion. -
-
fgrsa wrote:
I'm implement this solution, but don't have window alert or warning (flashes).How can enable this feature?
You dont see alerts and flashing because message window jump in the front of other windows. When the chat window is in the front it doesnt show alerts and the window doesnt flash. This issue should be fixed in the next patch.
Niklas, great. Thanx for you work
-
-
-
jmeijrink wrote:
- Make the taskbar icon change when the other party is writing a message / goes idle / etc. (Maybe the goes idle part is already implemented.)
You can check another Niklas patch here http://www.igniterealtime.org/community/thread/36161 (also spark.jar attached, but without history and tabbedpane patches).
SPARK-935 in my last comment. In that spark.jar it only works with tabs (cant drag them out), but you can see the status of the current tab in your taskbar.
-
-
-
-
Attaching the last compilation. Jorre, showing the presence of user in a detached tab is working and also it shows typing notification. Also it shows blinkin envelop icon when you get a message, though personally i would prefer to simple taskbar entry blinking as it is more visible. Such envelop icon blinking would fit for http://www.igniterealtime.org/issues/browse/
SPARK-971(blinking in systray).Jorre, issue with window being out of the bounds is still present, but it is not related to tabs being on the bottom of the window. It behaves the same with tabs on top. It puts detached tab titlebar at the mouse pointer position i think. Not a big issue if you window is in the middle of the screen and you drag upwards.
Clicking on message popup is fixed now.
There is still issue with MUC. Muc room is showing with offline icon in taskbar and i dont get message popups when new messages arrive in a room, and taskbar entry is not flashing. Also it shows bolded red room title even if muc room is focused and i have to click on that tab to make it not bolded-red.
This is so far the only issue i've found. Everything else i have reported is fixed.
-
Hi wroot,
About the replies in your post:
personally i would prefer to simple taskbar entry blinking as it is more visible. Such envelop icon blinking would fit for http://www.igniterealtime.org/issues/browse/
SPARK-971(blinking in systray).I do agree with you on this one, blinking taskbar entry is also default windows behaviour. Maybe both is best.
Jorre, issue with window being out of the bounds is still present, but it is not related to tabs being on the bottom of the window. It behaves the same with tabs on top. It puts detached tab titlebar at the mouse pointer position i think. Not a big issue if you window is in the middle of the screen and you drag upwards.
I also think it puts it the titlebar on the mouse pointer position, but it just feels unnattural that when you drag it only side-ways the new window is placed below the other window. I still think it would be more natural if only dragging side-ways would put the tab on the same height.
Kind regards,
Jorre
-
-
