YesNoOk
avatar

No development/release for another few days... (Read 17797 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.