Re: New icons for 1.1.21

2009-05-09 Thread Scott Ritchie

Warren Dumortier wrote:

2009/5/9 Scott Ritchie :

Warren Dumortier wrote:

Nice, however i have a little suggestion...
Would it be possible to assign an icon to WINE when you select a
program from the list? This would be nice! ;)

Huh?  It's not clear to me what you're referring to here.  Which list? Which
icon?

Thanks,
Scott Ritchie



Because i don't know how to explain it in english, i've made a little
screenshot: http://i44.tinypic.com/2rcxriu.png
Kind regards.




Ahh, I see what you mean now.  Thanks!  I'll get to work on it.

Thanks,
Scott Ritchie




Re: Shuttleworth on Wine

2009-05-09 Thread Austin English
2009/5/9 Nicklas Börjesson :
>> http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t124024892240
>> http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html
>
> Interesting project. At my workplace, we use TestComplete for testing 
> GUI-applications,
> I have had some problems finding similar applications for Linux, which is 
> kind of strange,
> since X11 should make it really easy to create positively fantastic testing 
> facilities.
>
> After reading about it, though, I still don't see what would be the point in 
> downloading
> the application as a part of the test, not being a part of the applications 
> functionality.

The idea is to make the test as automated as possible. That way anyone
can run the tests, not just people with certain programs.

-- 
-Austin




DIB Engine : Almost 100% working

2009-05-09 Thread Massimo Del Fedele

Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 
100%
operational.
On one of tested apps (MSN Messenger) it behaves even better than original one 
:-)

For whom wish to test it, bug 421 page.

Ciao

Max





RE: Shuttleworth on Wine

2009-05-09 Thread Nicklas Börjesson
> http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t124024892240
> http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html

Interesting project. At my workplace, we use TestComplete for testing 
GUI-applications, 
I have had some problems finding similar applications for Linux, which is kind 
of strange,
since X11 should make it really easy to create positively fantastic testing 
facilities.

After reading about it, though, I still don't see what would be the point in 
downloading
the application as a part of the test, not being a part of the applications 
functionality.

IMHO.

//Nicklas




Re: Shuttleworth on Wine

2009-05-09 Thread Austin English
2009/5/9 Nicklas Börjesson :
>
>
>>It's the registering/download manager that makes it not useful. It's
>>much harder to script all of that.
>
> Why script that? One doesn't need wine to download a file, right?
> I really don't see what the point would be to test that.
> Once you downloaded the file, you don't need to download that version
> again. The only thing that needs testing is the actual running of that
> file and the following installation.
> Why test the Adobe website?
> Or have I misunderstood you completely?

http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t124024892240
http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html

-- 
-Austin




Re: Shuttleworth on Wine

2009-05-09 Thread Austin English
2009/5/9 Nicklas Börjesson :
>>Photoshop, however, is harder to test,
>>since it doesn't have an easy free download available.
>
> Free photoshop trial download, you do need to register (and
> download through the "download manager") though:
> https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop

It's the registering/download manager that makes it not useful. It's
much harder to script all of that.

-- 
-Austin




Re: New icons for 1.1.21

2009-05-09 Thread Warren Dumortier
2009/5/9 Scott Ritchie :
> Warren Dumortier wrote:
>>
>> Nice, however i have a little suggestion...
>> Would it be possible to assign an icon to WINE when you select a
>> program from the list? This would be nice! ;)
>
> Huh?  It's not clear to me what you're referring to here.  Which list? Which
> icon?
>
> Thanks,
> Scott Ritchie
>

Because i don't know how to explain it in english, i've made a little
screenshot: http://i44.tinypic.com/2rcxriu.png
Kind regards.




Re: New icons for 1.1.21

2009-05-09 Thread Scott Ritchie

Warren Dumortier wrote:


Nice, however i have a little suggestion...
Would it be possible to assign an icon to WINE when you select a
program from the list? This would be nice! ;)


Huh?  It's not clear to me what you're referring to here.  Which list? 
Which icon?


Thanks,
Scott Ritchie




Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)

2009-05-09 Thread Vitaliy Margolen
Daniel Santos wrote:
> I think I just need to create a working solution and propose it as a
> patch.

It's already possible - see task manager. The only requirement for
disabling/enabling debug channels from within the progrm is the debug
channel have to be enabled at the start (WINEDEBUG=+all).

Vitaliy




Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr

2009-05-09 Thread Vitaliy Margolen
Few nitpicks about your patch.

Guy Albertelli wrote:

> +if (!(input = HeapAlloc( GetProcessHeap(), 0, i_size )))
> +{
> +SetLastError( ERROR_NOT_ENOUGH_MEMORY );
> +goto err_ret;
> +}
> +memset( input, 0, i_size );
To zero out allocated memory you should use HEAP_ZERO_MEMORY allocation flag:
input = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, i_size );

However there is no need to do any of that - do not just clear memory
without a good reason. It takes time to do it, especially that you doing it
several times.

What you do need to do in your code is explicitly zero-terminate all strings
you receive from mount manager after you copy them.

> +p = (WCHAR *) input;
This is wrong - types of "p" and "input" has nothing to do with each other.

> +p = (WCHAR*)((char *)input + sizeof(MOUNTMGR_MOUNT_POINT));
> +input->DeviceNameOffset = (char *)p - (char *)input;
> +memcpy( p, nonpersist_name, lstrlenW( nonpersist_name )*sizeof(WCHAR) );
> +input->DeviceNameLength = lstrlenW( nonpersist_name )*sizeof(WCHAR);
This is ugly. You can write it like this:

input->DeviceNameOffset = sizeof(*input);
input->DeviceNameLength = lstrlenW( nonpersist_name ) * sizeof(WCHAR)
memcpy( input + 1, nonpersist_name, input->DeviceNameLength );

> +/* is there space in the return variable ?? */
> +if ((o1->SymbolicLinkNameLength/sizeof(WCHAR))+2 > size)
> +{
> +SetLastError( ERROR_INVALID_PARAMETER );
> +goto err_ret;
> +}
This doesn't look right. There are several other error codes that more
appropriate. You should expand your tests to check what native returns here.
Also are you sure that "size" is in chars not bytes?

> +/* make string null terminated  */
> +p = (WCHAR*)((char*)volume + o1->SymbolicLinkNameLength);
> +memset( p, 0, sizeof(WCHAR) );
Again ugly. You can write it like:
volume[o1->SymbolicLinkNameLength / sizeof(WCHAR)] = 0;


> +if (input) HeapFree( GetProcessHeap(), 0, input );
> +if (output) HeapFree( GetProcessHeap(), 0, output );
You do not need to check for pointer != NULL before freeing it. All free()
functions already doing it.

Vitaliy.




Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)

2009-05-09 Thread Daniel Santos
What I'm proposing shouldn't interfere with that.  However, my original 
proposal is lacking (as I discovered when trying it out) because most of the 
object files that use debug logging end up with a static struct  
__wine_debug_channel variable that can't be changed from libwine after 
initialization.

I think I just need to create a working solution and propose it as a patch.  
Performance is a pretty huge issue where, especially when running with 
WINEDEBUG=+all, so whatever I come up with will have to be very performance 
sensitive.  Either way, the idea is to provide a mechanism for dynamically 
changing debug channels.  Since this isn't something that many people should 
need (and especially not end users) this should be disabled by default.

--- On Fri, 5/8/09, André Hentschel  wrote:

From: André Hentschel 
Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
To: daniel.san...@pobox.com, wine-devel@winehq.org
Date: Friday, May 8, 2009, 7:07 AM

The Problem with a pre-processor setting would be that the endusers may not be 
able to make good logs for the devs.
At the moment you can say to a user "send a log using 'WINEDEBUG=commctrl wine 
program.exe'", the user doesnt have to know what he is doing exactly, but he 
sends a usefull text. That wouldnt be possible anymore as i understand it.

Best regards André Hentschel

Daniel Santos schrieb:
> It would seem quite helpful for debugging odd situations to be able to turn 
> debugging on and off programmatically.  I like not having every debug class 
> loaded in memory by default (and everything that goes with maintaining that 
> global list), but it would seem quite helpful for troubleshooting, testing 
> and debugging special cases (mostly where one doesn't have the sources of the 
> troublesome app).
> 
> Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel to 
> debug_options if it doesn't exist and even allow setting the default_flags 
> (say by having a zero-length name in the channel argument) or even another 
> function which would allow it.  I'm not sure what thread synchronization 
> implications this would bring about (and the associated costs of the sync 
> objects), it seems it would require at the least the use of a critical 
> section to modify the debug_options, but perhaps this can be a pre-processor 
> driven option?  The configure could have a --enable-dynamic-channels or some 
> such that would set a pre-processor macro, etc.
> 
> Alternatively, a cheaper (hackier) mechanism of thread-safety could be 
> achived by having the debug_options be contained in a struct along with the 
> nb_debug_options and have them heap-allocated so that the debug_options 
> pointer could be changed in a single machine instruction.  A similar 
> mechanism (i.e., hack) could be use to free the old debug_options struct.  
> That's ugly, but I'm just presenting options.
> 
> Daniel
> 
> 
> 
> 
> 
>   




  


Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try3)

2009-05-09 Thread Vitaliy Margolen
André Hentschel wrote:
> now using SNDMSGW
> ---
>  dlls/comctl32/listview.c   |1 -
>  dlls/comctl32/tests/listview.c |8 
>  include/commctrl.h |6 ++
>  3 files changed, 14 insertions(+), 1 deletions(-)
> 
> +#define ListView_SetCheckState(hwndLV, iIndex, bCheck) \
> +{ LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask = 
> LVIS_STATEIMAGEMASK;\
> +SNDMSGW(hwndLV, LVM_SETITEMSTATE, (WPARAM)(INT)(iIndex), (LPARAM) 
> (LPLVITEMA)&_LVi);}
If you using SendMessageW you must use W structures (LVITEMW not LVITEMA).

Also why are you typecasting WP & LP two times?

Vitaliy.




Re: New icons for 1.1.21

2009-05-09 Thread Warren Dumortier
2009/5/9 Scott Ritchie :
> Hey everyone,
>
> I just wanted to say that the icon discussion I started a couple weeks back
> has born even more fruit, and I'm really happy with the current state of the
> icons that I'm now using in the 1.1.21 Ubuntu packages. I've attached them,
> and will be sending them as patches soon as well.
>
> I'm still not quite done with them, and they will likely change a bit after
> I get some UI feedback at the Ubuntu Developer Summit at the end of the
> month, but in the meantime I think they're quite better than what we have.
>
> Unlike the ubuntustudio icons I found (and packaged with 1.1.20 as an
> experiment), these should be a bit more visible (and fully tango-compliant).
>  In particular, the stem of the glass is no longer two semitransparent
> pixels at normal 48x48 size, but instead has a full Tango border/inner brush
> stroke.
>
> Smaller icons for the other standard sizes are being worked on as well,
> however they have to be retouched individually to maintain the 1 pixel
> border/brush stroke in the Tango style.  Eventually I'll submit a patch for
> our website's mini icon as well.
>
> Anyway, please feel free to give way too much feedback :)
>
> Thanks,
> Scott Ritchie
>
>
>
>

Nice, however i have a little suggestion...
Would it be possible to assign an icon to WINE when you select a
program from the list? This would be nice! ;)




Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try3)

2009-05-09 Thread Nikolay Sivov

André Hentschel wrote:

now using SNDMSGW
---
 dlls/comctl32/listview.c   |1 -
 dlls/comctl32/tests/listview.c |8 
 include/commctrl.h |6 ++
 3 files changed, 14 insertions(+), 1 deletions(-)
I still don't follow you. How will it run on systems without unicode 
support?
In general it's better to correct all A-only macros to SNDMSG. This 
eliminates problem

with missed SendMessageW and superfluous AtoW conversion when it's present.

In native header ListView_SetCheckSate is implemented as a wrapper over
ListView_SetItemState which in turn is defined as SNDMSG.





Re: Severity levels

2009-05-09 Thread Henri Verbeet
2009/5/9 Nicklas Börjesson :
>>When you're not subscribed to the list, your posts have to go through
>>moderation. Sometimes that can take a while.
>
> I do subscribe to the list(and did, from the beginning).
> Or maybe subscription is more than registering to the mailing list?
>
You also need to follow the confirmation link, of course, but if you
receive mails from the list that should be ok. The only other obvious
thing I can think of at the moment is to make sure you're sending
mails with the same address you're receiving them on.