YesNoOk
avatar

No development/release for another few days... (Read 17560 times)

Started by Nightwish, June 12, 2005, 16:33:17

0 Members and 1 Guest are viewing this.
Share this topic:
#1
No development/release for another few days... |
June 12, 2005, 16:33:17
Hi,

I'am getting new harddrive(s) for my main machine, and, as a result, I will have to re-install A LOT of stuff (my XP installation is running for more than a year now, so it's gotten HUGE :) )

I also plan to replace Visual Studio .NET 2003 with the latest beta of 2005 (which I received via MSDN), because I need that for non-miranda related stuff (basically, for my job). That shouldn't break anything in tabSRMM ore elsewhere, and even if it does, then I can still use GCC/MingW32 for building tabsrmm, which works.

So, doing all this stuff will take some time and I'am not going to have much time to put into tabSRMM related things for the next few days. No need to worry though, I'am still working on it, and the current CVS build is quite an improvement from the latest 95pre with font service support already working and a lot of bug fixes.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#2
Re: No development/release for another few days... |
June 17, 2005, 17:22:41
Ok, everything i mentioned above is complete now.

I'am gonna post a current change log here. A new build should be available this weekend. One word before - it would be a good idea to back up your current tabSRMM theme (using the export feature). The next release will move the fonts and colors somwhat around the database (because of added font service support). It shouldn't hurt, as tabSRMM takes care of moving the old settings to the new location when it detects old settings, but if something goes wrong (e.g. Miranda crashes at startup), then you may loose font settings.

Using the export/import feature will make it more safe.

Code:
* container icon and title is now set earlier so that the container does not
  show "Dialog" while tabs are created.
 
* fixed rtf parser to deal with some (rare) rich edit bugs.

* changed tab layouting for single AND multiline BUTTON tabs. Both modes are
  now using fixed width tabs and the layouting code will try to always "fill"
  the rows. An option to set the default fixed tab width has been added
  to the tab appearance configuration dialog.
 
+ new feature for event notifications (popups only):

  tabSRMM can now remove popups for a contact under the following situations:
 
  1) container receives focus
  2) you start typing a reply
  3) you send a reply
 
  The feature can be configured on the Options->Event Notifications page (in the
  listbox with all the checkboxes inside - at the very end of the list).
 
  Whenever one of these options is checked, tabSRMM will remove ALL popups for the
  contact when one of the above conditions is true. Note that you can combine them,
  but that doesn't make much sense. 1) (focus) always happens before any other event.
 
  The feature is pretty useful if you have multiple popups from a single contact on
  screen.
 
- removed status bar message "keyboard layout saved". No longer needed, because
  the keyboard layout is now always visible as 2-digit code in the 2nd status bar
  panel.
 
* minor layout changes in the message window. Toolbar buttons are slightly smaller
  and got a better look when using classic Windows theme (3d effect toned down a
  a bit).
 
* implemented a suggestion by Joe @ Whale, using IsUnicodeAscii() to check if a given
  message really needs to be sent as unicode. If not, the message is sent ANSI only.
  The advantage is that this may save A LOT of database / history size, because it
  avoids storing every message twice (both ansi and UCS-2 parts). With the new
  system, an UCS-2 part is only saved (and sent) when needed. Messages containing
  7bit characters only (0x00 - 0x7f, most latin characters) are safe to be sent as ansi.
 
! fixed bug with formatting buttons

* removed "ding" sounds when using some hotkeys (Alt-S for example)

* various langpack updates

* ICON PACK: updated "unknown.bmp" (default avatar image). Thanks to Faith for the
  .bmp.
 
* several (internal) changes to focus handling and tab activation. Some things have been
  simplified in the code, and in some areas additional safety checks were added.
  May result in new focus/redraw bugs, but overall, the new system is an
  improvement. It just needs to stabilize.
 
* toolbar buttons are now always "flat" when using visual styles under XP. They no
  longer use push button skinning. Beveled (3d) buttons are still available for
  classic windows theme.
 
* DISMISS EVENT is back, but with a big warning when you first activate it / and or
  run miranda with that option active. Also, it is only available for "click" actions,
  you cannot set dismiss event for the popup timeout action.

* the tab control is now a full window class, and no longer only subclassed.
                 
+ new hotkeys:
  ALT-I: quick show / hide the info panel
  ALT-B: toggle BiDi option (switch between RTL and LTR)
 
* new option to format the title bar using variables. The format string for the title
  bar is simple and may be up to 50 characters long. It can contain any text you want
  and the following variables as placeholders:
 
  %n - Nickname
  %p - protocol
  %u - UIN
  %s - Status mode
 
  You can set the default format string for all containers under Message Sessions->
  Message Window->Containers.
 
  You can also set a private title bar format string in the container options dialog.
  Just tick "use private title format" and set the format template string.
 
* possible fix for a rare redrawing bug, resulting in black background on tabs (visual
  styles, tabs at the top only).

* prevent custom template background colors from taking the rgb value 0,0,0 to avoid
  a problem with icon transparency and "pure" black bg color. A pure black bg color
  is converted to rgb(1,1,1).
                                                         g
+ added support for the FontService plugin by sje to customize message window fonts and back-
  grounds. If font service plugin is enabled, tabSRMMs own font+color configuration page
  is disabled. However, tabSRMM still maintains its own copy of font + color settings in
  the DB so that you can switch between using font service and the old dialog easily.

+ restored "mark on double click" for the message history log.

* the info panel splitter now follows the settings for the normal splitter (global, private
  saving policy etc.).
 
+ added visual styles support for button tabs (using pushbutton skins).

! fixed transparency issues when changing focus

+ activating the smiley selection window does no longer switch containers transparency to
  "inactive".
  NOTE: requires new build of smileyadd.dll (included in this release) and does NOT work
  with IEViews smiley selection window. Sorry for that, but it needs a small change in
  the smiley selection window code. So I would have to distribute a modified IEView aswell
  (which I don't like).
 
+ added global options for container(s). The container options dialog now allows you to
  set the options for any container to "global" or "private". All containers using global
  options share one set of container configuration flags (and transparency values).
  Title bar format and container window position/size can be set independently to either
  global or private.
 
+ added the info panel allowing for dual avatar display.

Pretty long list, but that's basically all for now.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#3
Re: No development/release for another few days... |
June 17, 2005, 19:35:13
How do I back up tabsrmm theme? Do you mean the message sessions->message log->template sets: "standard templates" then "save template" if we played around with that? Or am I missing another export option?
#4
Re: No development/release for another few days... |
June 17, 2005, 19:46:58
Container toolbar -> Message log options -> Export/Import Message Log Settings...
#5
x-mas in June... |
June 17, 2005, 20:37:17
Realy big list...

Yeah! This weekend is x-mas!  ;D

BigBug
#6
Re: x-mas in June... |
June 18, 2005, 05:24:23
#7
Re: No development/release for another few days... |
June 18, 2005, 17:34:32
Can't wait :)
#8
Re: No development/release for another few days... |
June 18, 2005, 18:14:15
Code:
+ activating the smiley selection window does no longer switch containers transparency to
  "inactive".
  NOTE: requires new build of smileyadd.dll (included in this release) and does NOT work
  with IEViews smiley selection window. Sorry for that, but it needs a small change in
  the smiley selection window code. So I would have to distribute a modified IEView aswell
  (which I don't like).

What happens if we try to activate the smiley selection window when using ieview ? It just won't show ? or will it crash ? :(
I'm using the stable ieview version (1.0.2.2) and i don't want to switch to the unstable verstion just for this.
If it just won't show the window then no problem, i'll start memorizing emoticons :)
#9
Re: No development/release for another few days... |
June 18, 2005, 19:22:51
I MUST praise you ;D
really nice work, much appreciated  :o
#10
Re: No development/release for another few days... |
June 18, 2005, 20:54:28
What happens if we try to activate the smiley selection window when using ieview ? It just won't show ? or will it crash ? :(

Um, no. Nothing *bad* will happen, of course. The container may change its transparency to the "inactive" (unfocused) value (like it always did when opening the smiley selection window), but that's all.

The change is specific to smileyadd and does not affect IEView's smiley selection in any way.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#11
Re: No development/release for another few days... |
June 19, 2005, 20:50:08
#12
Re: No development/release for another few days... |
June 19, 2005, 21:05:35
#13
Re: No development/release for another few days... |
June 19, 2005, 22:01:50
And I said, it *should* be available this weekend.

Unfortunately, I was a bit low on time and couldn't complete everyhing I wanted to do for this build. But it's very close...

I'am still thinking about a solution for showing the status message in the new info panel. Most likely, I'll do it with a tooltip, but I'am not completely sure right now.

Retrieving the status message should only happen "on demand" in Miranda, because it's not cached and requires network access each time you do it (and if you do it automatically, it may become performance issue with many tabs open).
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#14
Re: No development/release for another few days... |
June 20, 2005, 00:27:11
Nightwish, I'm using the 06-19 15:10 CVS version of TabSRMM and I wanted to tell you a few things I found before you release .95.

1.  Focusing the container window doesn't always make it stop flashing.  Sometimes it won't quit until I click a tab or double-click the input field.
2.  The bottom of the new button in the status bar gets cut off and doesn't match the appearance of the other buttons (attachment 1)
3.  The visibility button in the info panel doesn't show the icon, i hovered over the button to show it is there. (attachment 2)
4.  Sometimes splitter width doesn't match between tabs though I'm using global splitter position and the 'panelheight' info is saved for each contact in the DB, which didn't make sense to me.  It seems to only happen when using 'static' avatar display.
#15
Re: No development/release for another few days... |
June 20, 2005, 05:02:18
__
Best regardz, Faith Healer
#16
Re: No development/release for another few days... |
June 20, 2005, 07:01:31
Also, if I hover over a button and then move the pointer to the message log before a tooltip appears, the tooltips for the text formatting or emoticon buttons are shown and then destroyed when they finish being drawn.  I have those buttons hidden.
#17
Re: No development/release for another few days... |
June 20, 2005, 09:26:41
Also, if I hover over a button and then move the pointer to the message log before a tooltip appears, the tooltips for the text formatting or emoticon buttons are shown and then destroyed when they finish being drawn.  I have those buttons hidden.

Thats normal. These buttons are still there and there is no way to prevent the tooltips from showing up.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#18
Re: No development/release for another few days... |
June 20, 2005, 16:24:31
I'am still thinking about a solution for showing the status message in the new info panel. Most likely, I'll do it with a tooltip, but I'am not completely sure right now.

Retrieving the status message should only happen "on demand" in Miranda, because it's not cached and requires network access each time you do it (and if you do it automatically, it may become performance issue with many tabs open).


That'd be neat. Just make it a tooltip, over the area that shows the current contact status.
#19
Re: No development/release for another few days... |
June 20, 2005, 17:18:06
That'd be neat. Just make it a tooltip, over the area that shows the current contact status.

Yep, done that way. The tooltip appears when you hover the status field (after some small delay of about half a second to avoid a tooltip when just "touching" the field with the mouse). It requests the awaymsg "on the fly" but there is a timer to prevent "awaymsg floods", so the awaymsg is cached for a few minutes.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#20
Re: No development/release for another few days... |
June 20, 2005, 18:22:19
So does it check if it has changed, or not? It just displays the cached message during those minutes? Some of my contacts may change it more than one time in a few minutes... I guess the displayed message wouldn't be correct then? How does mToolTip solve the problem? It looks like it doesn't have a floodtimer or caches anything...
#21
Re: No development/release for another few days... |
June 20, 2005, 18:40:49
How does mToolTip solve the problem? It looks like it doesn't have a floodtimer or caches anything...
AFAIK every time you take the Tooltip anew mToolTip reloads it again
#22
Re: No development/release for another few days... |
June 20, 2005, 18:56:50
So does it check if it has changed, or not? It just displays the cached message during those minutes?

It does not re-check it before the timer has elapsed. It's not possible to determine if it has changed without sending a complete request via the protocol.

And please don't ask for changing that system, as I won't. I don't think it's a problem to have the awaymsg not being up to date for a minute (the timer is exactly 60 seconds). If people would change awaymsg more than once per minute, I would ask myself if they don't have anything better to do and just ignore that game :)

Quote
Some of my contacts may change it more than one time in a few minutes... I guess the displayed message wouldn't be correct then? How does mToolTip solve the problem? It looks like it doesn't have a floodtimer or caches anything...

mtooltip just requests the awaymsg everytime you hover a contact.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#23
Re: No development/release for another few days... |
June 20, 2005, 20:00:50
can i disable that reading?
yes i know... more options... but since reading the status msg in ICQ is not stealth, i don't want it to popup by mistake
#24
Re: No development/release for another few days... |
June 20, 2005, 21:56:10
can i disable that reading?
yes i know... more options... but since reading the status msg in ICQ is not stealth, i don't want it to popup by mistake

Well, maybe a good idea to switch it off, although, you need to hover for more than half a second over the status field (which is quite small). Chances to do this "by accident" are small, but still possible :)

__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#25
Re: No development/release for another few days... |
June 21, 2005, 01:44:33
1.  Focusing the container window doesn't always make it stop flashing.  Sometimes it won't quit until I click a tab or double-click the input field.
Hey, this also happens for 'unread event' icon.
#26
Re: No development/release for another few days... |
June 21, 2005, 16:26:35
I would be bitching a lot more if I didn't have other ways of reading the status message (NewStatusNotify & mToolTip for two). Sometimes a contact changes status message to say where he or she is going, right before they're leaving, and I want to be able to read what it says right then, that's my only problem. But it's not a problem.
#27
Re: No development/release for another few days... |
June 21, 2005, 16:39:53
I would be bitching a lot more if I didn't have other ways of reading the status message (NewStatusNotify & mToolTip for two). Sometimes a contact changes status message to say where he or she is going, right before they're leaving, and I want to be able to read what it says right then, that's my only problem. But it's not a problem.

Just to make sure: The tabSRMM timer doesn't affect other plugins. You can still read the status msg with mtooltip or another plugin, even if you read it in the message window 10 seconds before.

The timer only affects the tooltip - it's also there to avoid possible problems with "infinite" loops.

While playing with this stuff, I discovered an interesting bug which results in a complete hang of the operating system (no bluescreen, just frozen until you reset). It basically happens with 2 miranda clients running on the same machine (but also works, with one miranda and one other client - qip for example) and requesting the status message very often (often, in that case, means, a few thousand times per *second*). The problem seems to be related to the SP2 firewall, because, on another maching running SP1 w/o firewall, it just crashed miranda).
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#28
Re: No development/release for another few days... |
June 21, 2005, 17:57:04
I would be bitching a lot more if I didn't have other ways of reading the status message (NewStatusNotify & mToolTip for two). Sometimes a contact changes status message to say where he or she is going, right before they're leaving, and I want to be able to read what it says right then, that's my only problem. But it's not a problem.

Just to make sure: The tabSRMM timer doesn't affect other plugins. You can still read the status msg with mtooltip or another plugin, even if you read it in the message window 10 seconds before.

Yeah, I knew that. :) That's why I said it's really not a problem.

While playing with this stuff, I discovered an interesting bug which results in a complete hang of the operating system (no bluescreen, just frozen until you reset). It basically happens with 2 miranda clients running on the same machine (but also works, with one miranda and one other client - qip for example) and requesting the status message very often (often, in that case, means, a few thousand times per *second*). The problem seems to be related to the SP2 firewall, because, on another maching running SP1 w/o firewall, it just crashed miranda).

That's freaky. Kind of like that line of HTML code that crashed a whole lot of computers a week ago or something, with Win XP and IE or Firefox. Don't remember any URL. Or maybe that was worse, but anyway.
#29
Re: No development/release for another few days... |
June 21, 2005, 18:56:36
you mean the one described here
http://channel9.msdn.com/ShowPost.aspx?PostID=79311

that's an evil one
there is another mirror in the 4th page there

of course there is nothing in common between using 2 clients +asking for a status msg a few thousand times per sec and entering a website...
#30
Re: No development/release for another few days... |
June 21, 2005, 19:02:12
you mean the one described here
http://channel9.msdn.com/ShowPost.aspx?PostID=79311

of course there is nothing in common between using 2 clients +asking for a status msg a few thousand times per sec and entering a website...

This is the GDI problem which is, as far as I know, related to the video card driver in use. Basically, it's a memory allocation problem, and yes, it's evil but in no way related to the issue I found.

I was never able to reproduce the problem with the bluescreen when trying to open an *extremley* larg <img src link, but for many people, it worked and crashed windows hard.

__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#31
Re: No development/release for another few days... |
June 22, 2005, 02:51:47
Me neither actually... and yeah of course these two issues aren't related, in any other way than that they hang Windows.
#32
Re: No development/release for another few days... |
June 22, 2005, 16:35:35
Will the next release take much longer ? ;D
I'm asking because i want to check that hotkey thing i was talking about a while back and i'd like to start working on it after you release the new version.
#33
Re: No development/release for another few days... |
June 22, 2005, 16:43:58
Will the next release take much longer ? ;D
I'm asking because i want to check that hotkey thing i was talking about a while back and i'd like to start working on it after you release the new version.

Nope. It won't take long. I've still found a few minor issues to correct, but the "big picture" is fairly complete.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
#34
Re: No development/release for another few days... |
June 22, 2005, 17:28:47
Maybe we'll get a 0.1.0.0 version for tabSRMM's first birthday... :D it's in a month... ;D
#35
Re: No development/release for another few days... |
June 22, 2005, 20:29:55
Maybe we'll get a 0.1.0.0 version for tabSRMM's first birthday... :D it's in a month... ;D
TabSRMM is past version 0.1.0.0
Currently at 0.9.9.95 PRE

I think you mean 1.0.0.0
Or would it just be called 1.0 ?
#36
Re: No development/release for another few days... |
June 22, 2005, 20:41:00
TabSRMM is past version 0.1.0.0
Currently at 0.9.9.95 PRE

I think you mean 1.0.0.0
Or would it just be called 1.0 ?
Whatever...

Actually I checked the changelog file and there never was a 0.1.0.0 version... there was 0.0.9.5 and next, out of the sudden, was 0.9.9.0... ;D
#37
Re: No development/release for another few days... |
June 23, 2005, 20:33:41
can't wait any longer  ;)
#38
Re: No development/release for another few days... |
June 23, 2005, 21:01:26
I just found the tooltip for sending typing notifications. So there *is* a tooltip for typing notifications for the unicode version after all :)
The rectangle in which it shows is off though, i can only get it to show it the left top side of the icon, whereas the tooltip for sounds shows anywhere on the sound icon. Looks like the rectangle is a whee bit small :)
#39
Re: No development/release for another few days... |
June 25, 2005, 13:53:43
hello,

I was wondering, since the release of this new build is taking considerably longer than previously expected, would any of you building from CVS care to share builds with the rest of us? I'd love to try it out, the new features and layout of the chat window look wonderful.
#40
Re: No development/release for another few days... |
June 25, 2005, 23:46:17
#41
Re: No development/release for another few days... |
June 26, 2005, 02:34:23
Much appreciated, Lokke :)
#42
Re: No development/release for another few days... |
June 26, 2005, 14:52:43
So the CVS version is safe to use?
#43
Re: No development/release for another few days... |
June 26, 2005, 15:29:12
#44
Re: No development/release for another few days... |
June 26, 2005, 15:47:48
So the CVS version is safe to use?

Usually it is. You should however expect minor problems or sometimes unfinished new code.

Also, I'am not going to comment bug reports for cvs builds, because, in many cases, an issue which appears to be a bug might very well be just unfinished code.
__
Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to a single instruction that doesn't work.
My SMF-based forum fork
Last Edit: June 26, 2005, 15:56:19 by Nightwish