Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Simulating native widgets by taking screen captures / screenshots / snapshots
Simulating native widgets by taking screen captures / screenshots / snapshots [message #520251] |
Thu, 11 March 2010 11:50  |
Eclipse User |
|
|
|
Hello.
In the application I am working on, we are using a table widget (such as
NatTable, or KTable), that is a custom-drawn Canvas, for use with a very
large number of rows.
With that, we would like to have simple widgets like buttons and
checkboxes on that table, but because the table has a large dataset, we
rather not have true native widgets for every row, otherwise we might
hit OS limitations or performance problems, like Windows has.
So currently, we try to simulate the widgets by custom-drawing them
ourselves, while maintaining the native look. We do this by creating a
temporary shell, creating a real button/checkbox on the shell, and
taking a screen capture of the button/checkbox (in different states,
like selected, unselected, disabled, etc.), using an SWT GC.
The shell is created with SWT.ON_TOP, to ensure that when the screen
capture is done, no other windows are on top of the checkbox. (A problem
that occurs often otherwise, in Windows XP at least, making the
screenshot invalid.)
But this still feels like a bit of a hack, so I was wondering if anyone
had any insights on this issue, perhaps a way to improve on this
simulation technique, perhaps some problems that we haven't foreseen
yet, or perhaps another idea altogether?
Bruno Medeiros
|
|
|
Re: Simulating native widgets by taking screen captures / screenshots / snapshots [message #520252 is a reply to message #520251] |
Thu, 11 March 2010 11:58   |
Eclipse User |
|
|
|
Am 11.03.2010 17:50, schrieb Bruno Medeiros:
> Hello.
>
> In the application I am working on, we are using a table widget (such as
> NatTable, or KTable), that is a custom-drawn Canvas, for use with a very
> large number of rows.
> With that, we would like to have simple widgets like buttons and
> checkboxes on that table, but because the table has a large dataset, we
> rather not have true native widgets for every row, otherwise we might
> hit OS limitations or performance problems, like Windows has.
>
> So currently, we try to simulate the widgets by custom-drawing them
> ourselves, while maintaining the native look. We do this by creating a
> temporary shell, creating a real button/checkbox on the shell, and
> taking a screen capture of the button/checkbox (in different states,
> like selected, unselected, disabled, etc.), using an SWT GC.
> The shell is created with SWT.ON_TOP, to ensure that when the screen
> capture is done, no other windows are on top of the checkbox. (A problem
> that occurs often otherwise, in Windows XP at least, making the
> screenshot invalid.)
>
> But this still feels like a bit of a hack, so I was wondering if anyone
> had any insights on this issue, perhaps a way to improve on this
> simulation technique, perhaps some problems that we haven't foreseen
> yet, or perhaps another idea altogether?
>
>
> Bruno Medeiros
My Approach would be checking for which items are in view and creating
for them the widgets on the fly.. and disposing any which go out of view.
and using the usual methods for widgets on table .. i.e. TableEditor.
|
|
|
Re: Simulating native widgets by taking screen captures / screenshots / snapshots [message #520973 is a reply to message #520251] |
Mon, 15 March 2010 21:22   |
Eclipse User |
|
|
|
Bruno Medeiros wrote:
> Hello.
>
> In the application I am working on, we are using a table widget (such as
> NatTable, or KTable), that is a custom-drawn Canvas, for use with a very
> large number of rows.
> With that, we would like to have simple widgets like buttons and
> checkboxes on that table, but because the table has a large dataset, we
> rather not have true native widgets for every row, otherwise we might
> hit OS limitations or performance problems, like Windows has.
>
> So currently, we try to simulate the widgets by custom-drawing them
> ourselves, while maintaining the native look. We do this by creating a
> temporary shell, creating a real button/checkbox on the shell, and
> taking a screen capture of the button/checkbox (in different states,
> like selected, unselected, disabled, etc.), using an SWT GC.
> The shell is created with SWT.ON_TOP, to ensure that when the screen
> capture is done, no other windows are on top of the checkbox. (A problem
> that occurs often otherwise, in Windows XP at least, making the
> screenshot invalid.)
>
> But this still feels like a bit of a hack, so I was wondering if anyone
> had any insights on this issue, perhaps a way to improve on this
> simulation technique, perhaps some problems that we haven't foreseen
> yet, or perhaps another idea altogether?
>
>
> Bruno Medeiros
Bruno,
How are you going about taking the screen capture? (for example, getting
the bounds of the widget whose image you want to take, thus only getting
the widget in the capture. And how are you saving it?)
LG
|
|
|
Re: Simulating native widgets by taking screen captures / screenshots / snapshots [message #521020 is a reply to message #520251] |
Tue, 16 March 2010 04:53   |
Eclipse User |
|
|
|
Hi,
No using images is the only solution. Take a look here [1] on how we
used this to provide a TableViewer with native Checkboxes and futher
improvements [2].
[1] http://wiki.eclipse.org/JFaceSnippets#Snippet061FakedNativeC ellEditor
[2]https://bugs.eclipse.org/bugs/show_bug.cgi?id=301705
Tom
Am 11.03.10 17:50, schrieb Bruno Medeiros:
> Hello.
>
> In the application I am working on, we are using a table widget (such as
> NatTable, or KTable), that is a custom-drawn Canvas, for use with a very
> large number of rows.
> With that, we would like to have simple widgets like buttons and
> checkboxes on that table, but because the table has a large dataset, we
> rather not have true native widgets for every row, otherwise we might
> hit OS limitations or performance problems, like Windows has.
>
> So currently, we try to simulate the widgets by custom-drawing them
> ourselves, while maintaining the native look. We do this by creating a
> temporary shell, creating a real button/checkbox on the shell, and
> taking a screen capture of the button/checkbox (in different states,
> like selected, unselected, disabled, etc.), using an SWT GC.
> The shell is created with SWT.ON_TOP, to ensure that when the screen
> capture is done, no other windows are on top of the checkbox. (A problem
> that occurs often otherwise, in Windows XP at least, making the
> screenshot invalid.)
>
> But this still feels like a bit of a hack, so I was wondering if anyone
> had any insights on this issue, perhaps a way to improve on this
> simulation technique, perhaps some problems that we haven't foreseen
> yet, or perhaps another idea altogether?
>
>
> Bruno Medeiros
|
|
| | |
Re: Simulating native widgets by taking screen captures / screenshots / snapshots [message #521534 is a reply to message #521387] |
Wed, 17 March 2010 19:22  |
Eclipse User |
|
|
|
Tom Schindl wrote:
> Am 17.03.10 14:06, schrieb Bruno Medeiros:
>> On 16/03/2010 08:53, Tom Schindl wrote:
>>> Hi,
>>>
>>> No using images is the only solution. Take a look here [1] on how we
>>> used this to provide a TableViewer with native Checkboxes and futher
>>> improvements [2].
>>>
>> Is it really the only solution? What about Christian's idea of creating
>> and disposing widgets on the fly, as the view is scrolled? It sounds
>> interesting, but does it have any problems in practice?
>
> Positioning is an extra task and your control will not behave as good as
> it would with images beside that your need of handles will increase in
> linear with the number of Widgets visible, even if all of them display
> e.g. the same information whereas with images you can produce reuse.
>
> Tom
I agree with Tom that this is the best solution. That's why I was
asking how you had implemented the screen capture (or widget capture).
Making sure you have an "as optimized as possible" process to handle
that would help with performance.
The links Tom gave should be helpful.
LG
|
|
|
Goto Forum:
Current Time: Fri Jul 25 09:34:00 EDT 2025
Powered by FUDForum. Page generated in 0.07047 seconds
|