- make ListView / TableView / TreeView extend a common base class
(maybe abstract), because they share some operations, and many times I
have to make changes in all them …
There are two main challenges here:
- The selection state of a ListView or TableView is represented as a collection
of
- The selection state of a ListView or TableView is represented as a
collection of integers, whereas in TreeView it is a collection of lists of
integers. So you could probably share selection management code pretty
easily between ListView and TableView, but maybe not TreeView.
Yes I know
The JSON spec does define date or calendar types, so JSONSerializer does not
support them.
That's the real question for this, because usually beans used as a
data model (for example for business applications) many times have
data directly not supported, so the idea to provide something
No, this is not possible.
On May 4, 2012, at 2:28 PM, Andrei Pozolotin wrote:
Hello;
I am curious is there a way to do dynamic theme switch
in a running application w/o re-creating all of the components?
Thank you,
Andrei
I don't believe there are any legal issues regarding file names. As I recall,
we chose to include the version number in the file name simply because it is a
common convention to do so (and also because Maven requires it).
G
On Apr 30, 2012, at 12:54 PM, Roger L. Whitcomb wrote:
Hi everyone,
Not a private issue.
I'd suggest trying it first, and contact infra if it doesn't work.
G
On Jan 26, 2012, at 6:05 AM, Sandro Martini wrote:
Hi all,
in Apache Pivot web site I have just added the ability to execute Java
client side applications using Java Web Start (triggered by jnlp
Sandro, congratulations and thank you for volunteering!
By the way Martijn, I did spend some time as PMC Chair myself. ;-)
On Jan 24, 2012, at 3:20 PM, Martijn Dashorst wrote:
Please welcome Sandro as our Chair for Pivot!
With little time to spare, Todd wanted to resign as Chair for our
a crazy idea come to my mind from what I start to read, it seems that
WebGL will be more and more present in our future …
FYI - last I checked, Microsoft had not committed to this standard, though that
may have changed.
It's not clear to me if HTML5 Canvas should be enough
IMO, the biggest
FYI, the 3.0 code was removed because I was not legally allowed to contribute
it. So unfortunately you won't be able to use that as a starting point.
On Nov 16, 2011, at 8:47 AM, Sandro Martini sandro.mart...@gmail.com wrote:
Hi Niclas,
My work is visible on GitHub. niclash/pivot
Ok, found
Just after the pluggable AWT backend I see even a pluggable JavaFX 2
backend (if compatible by license)
I don't think there would be any licensing issues, but there would definitely
be an impedance mismatch here since JavaFX doesn't currently provide any
public immediate-mode drawing API.
This is actually something I had considered attempting myself a couple of years
back. One challenge that you may run into is text measurement. HTML 5 does not
provide a means for calculating font metrics. I emailed the HTML 5 working
group about this a while back, but they did not have any
What Pivot version are you using? I think this may have been fixed for 2.0.1.
On Nov 9, 2011, at 2:09 PM, Alvaro Zamorano wrote:
Dear friends
I´m java developer and in this moment i use pivot api, during test i found
some error in the calendar, in the year 2012 month january the problem is
One great improvement of Subversion 1.7 is for example that it now
creates only one .svn folder (and no more one per folder under source
control).
That IS a nice improvement! :-)
Also, please subscribe to the user list if you want to see a response.
On Oct 18, 2011, at 10:00 AM, Edvin Syse wrote:
Please ask your question on the user list, this is not a dev question :)
-- Edvin
-Opprinnelig melding-
Fra: V SANTOSH PAVAN RAJU BS
tableView.removeSelectedIndex(rowIndex);
removeSelectedIndex() removes the given value from the list of selected
indexes. It does not remove the item from the model. You can use List#remove()
to do that.
FYI, I'm moving this to the user list since it isn't a dev question - please
make sure
Did you try opening the dialog with the main frame as its owner? That will
ensure that it remains on top of the frame.
Yes, but then I don't get it to be non-modal even if I use the setModal
(false) on the dialog. So I can't continue to use the main frames menus and
buttons. Or am I
not be in the business of maintaining forked Pivot libraries.
On Sat, Oct 8, 2011 at 4:28 PM, Greg Brown gk_br...@verizon.net wrote:
But again, the problem with recursively setting the enabled flag is that
you blow away any existing state. That's why I think simply painting the
disabled state
, to have more
info in the issue.
Sandro
2011/10/11 Greg Brown gk_br...@verizon.net:
Did you try applying a decorator to your container? For example,
ShadeDecorator might work.
On Oct 10, 2011, at 5:27 PM, Bill van Melle wrote:
Exactly. I think Noel is being distracted by the proposal
Yes, you just need to attach an editor to your table. See:
http://pivot.apache.org/demos/table-row-editor.html
http://svn.apache.org/repos/asf/pivot/trunk/demos/src/org/apache/pivot/demos/roweditor/
On Oct 11, 2011, at 4:10 AM, V SANTOSH PAVAN RAJU BS wrote:
I have created a row dynamically in
It took me a while to figure out I could simply
override the skin's enabledChanged method to add or remove the decorator,
but now I'm good.
Another option is to listen for changes to the enabled property of the
container, if that makes sense for your app.
That's what isBlocked() does.
On Oct 8, 2011, at 7:23 AM, DreamTangerine wrote:
A quick thought and question :
Why not implement isEnabled() using parent isEnabled() ?
public boolean isEnabled() {
if (null == getParent())
return enabled;
else
return
But again, the problem with recursively setting the enabled flag is that you
blow away any existing state. That's why I think simply painting the disabled
state when isBlocked() is true would be preferable.
On Oct 8, 2011, at 1:10 AM, Noel Grandin wrote:
On Sat, Oct 8, 2011 at 01:49, Bill van
Finally, permit me to quibble with the proposal to keep the current behavior
as default. I think it's a bad default. It violates the principle of
don't surprise the user. If the user can't interact with a portion of the
UI, that portion shouldn't be painted in a way that invites the user
Well, you'd basically be talking about moving just the Drawing class into
its own JAR, which doesn't seem worth it.
Classes to more would be: Drawing, Image, SVGDiagramSerializer classes all
inside Wtk.
Image is the base class for Picture and some other internal image classes as
well.
Again, I don't personally see any value in doing this. There is no issue in
having a dependency on the SVG JARs, either from a licensing or deployment
perspective, and you'd only be saving a single class (Drawing) in the WTK JAR.
You'd need to add it to another JAR, which will probably
So there's no need to use a service provider - the JVM already takes care of
that.
Actually, the class loader handles this, not the JVM. But either way, it isn't
something that we need to worry about.
Bartlett wrote:
On 8 September 2011 21:36, Greg Brown gk_br...@verizon.net wrote:
I have only scanned this thread quickly and haven't examined the code,
but couldn't the SVG stuff be moved into a separate JAR as Sandro
suggested, after modifying the relevant
BXMLSerializer/Image/Drawing/whatever
Ah, OK. I have considered a similar extensibility mechanism in the past,
using a static map of file extension to SerializerImage that the Image
class would use to determine how to load a given image URL. But maybe a
service provider would work better.
Does that mean you would reconsider
Note that there is no build-time dependency on SVG Salamander for projects -
only for the platform.
By the way, by projects, I assumed you meant applications. Let me know if
that is not correct.
The plugin works in 3.5 and 3.6 - not sure about 3.7. You should just be able
to export that project as a plugin and add it to your Eclipse installation to
test it.
On Sep 7, 2011, at 12:38 PM, Sandro Martini wrote:
Hi all,
just imported all Pivot sources (from trunk) in eclipse Helios
The idea is to keep it inside Pivot core workspace, but moving dependency on
SVG Salamander in this new (small) project (with its jar), so anyone not
using SVG features won't have a dependency on SVG Salamander.
You don't need to do this. If an app does not refer to the Drawing class, it
Well, you'd basically be talking about moving just the Drawing class into its
own JAR, which doesn't seem worth it. You'd also need to remove the support in
the Image class for loading Drawings, so you'd no longer be able to do this:
ImageView image=@foo.png/
On Sep 7, 2011, at 1:13 PM,
Thank you for clarifying. That is strange. I don't know why that space is
there. Maybe someone else has an idea?
On Sep 1, 2011, at 10:28 AM, prophe wrote:
Look at the picture - The filter table has a space between editor and header
of table! This editor doesn't looks like the editor in main
[
https://issues.apache.org/jira/browse/PIVOT-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093842#comment-13093842
]
Greg Brown commented on PIVOT-792:
--
Perhaps a fix would be for the callback to check
[
https://issues.apache.org/jira/browse/PIVOT-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093876#comment-13093876
]
Greg Brown commented on PIVOT-792:
--
Where are you envisioning the weak reference would
FWIW, I think overloading BoxPane would add more complexity. I'd prefer either
a new component or recommending StackPane or ScrollPane for this use case.
G
- Reply message -
From: Noel Grandin (JIRA) j...@apache.org
Date: Tue, Aug 23, 2011 3:20 pm
Subject: [jira] [Commented] (PIVOT-790)
The concept of a FillPane has come up before. But since we have a couple other
containers that can do the same thing (StackPane, ScrollPane, TablePane), it
never seemed worth it. But it would certainly be easy enough to add.
On Aug 19, 2011, at 1:56 PM, Roger L. Whitcomb wrote:
In some places
I could see an argument for adding such a utility for Sequence (though
unfortunately you wouldn't be able to add a corresponding version for
Dictionary, since a dictionary doesn't provide any means of enumerating its
keys).
On Aug 15, 2011, at 4:50 PM, Chris Bartlett wrote:
I'm not sure how
Just a reminder to make sure that all committers are registered for the commits
mailing list. I have been getting moderation requests for checkins -
subscribing to comm...@pivot.apache.org should resolve that.
Thanks,
G
Is Martijn active on Pivot?
Martijn was one of Pivot's mentors while the project was in incubation, and he
is still a member of the PMC.
G
Sandro, have you tried adding Edvin yourself? You should have admin rights in
JIRA now.
On Aug 9, 2011, at 8:56 AM, Sandro Martini wrote:
You should use its apache mail, I hope soon Chris will send to you a private
mail with the name of the account.
Thank you again.
Last, I've seen that
And, under the Administrators role I see even Chris and Roger, while
Martijn and Niclas are missing ... I think here should be better to have
only Pivot PMC members, ok (of course nothing against people here, just to
make some cleanup :-) ) ?
Sure.
Done
On Aug 6, 2011, at 5:14 AM, Sandro Martini wrote:
Greg, can you add to me and other PMC members full grants on Pivot JIRA ?
Otherwise we aren'r able for example to open a new release needed now to
move 2.0.1 tickets to 2.0.2, and useful for the future too).
Currently only you and Todd
That's cool - I was not aware of that feature.
On Aug 8, 2011, at 8:39 AM, Chris Bartlett wrote:
Is there any reason why the DefaultProperty annotation is not
annotated itself with java.lang.annotation.Documented?
Doing so means that users will be able to see what WTK (or other)
classes
Just played around with @BXML, and don't see much value there.
If the fields are private (the common case) then I tend to agree, since they
wouldn't be Javadoc'ed anyways.
I'm not saying that it would help to enhance the Pivot API Javadocs in
any way. Just that it would be there for Pivot consumers when they
generate Javadocs for their own code that uses @BXML.
@BXML is primarily meant for application, not platform, usage anyways, so
that's OK. I'm just
me put it this way - if annotations were *included* in Javadocs
by default (as opposed to being *excluded* by default), I wouldn't be
able to suggest a good reason to *exclude* the @BXML annotation.
On 8 August 2011 21:07, Greg Brown gk_br...@verizon.net wrote:
I'm not saying that it would
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080037#comment-13080037
]
Greg Brown commented on PIVOT-694:
--
This issue has nothing to do with repaint() - it only
My feeling is that maintenance releases can be released at any time - there's
no need to wait for a particular feature set to be complete. You could do a
2.0.2 release the next day if you wanted to. So I'd suggest starting the
release process sooner rather than later. But that's just my
Yes, releases are generally tagged. But I'd hold off on creating the tag until
the QA part is done.
On Aug 5, 2011, at 3:21 PM, Sandro Martini wrote:
Thinking on it I think that we could start next week the proposal for the
2.0.1 , but please don't create a branch in svn, maybe create a tag
Makes sense.
On Aug 5, 2011, at 3:24 PM, Roger L. Whitcomb wrote:
What if we do this?
- We need a tag for a release version, so do a 2.0.1 tag,
- We will need continued work on further 2.0.x releases, so make a 2.0.x
branch
- Change trunk to be the 2.1 working version
Roger Whitcomb |
Someone of us has some file to commit before tagging ?
I haven't ...
You may have missed this in my earlier message, but I'd recommend waiting until
testing is finished before tagging. Otherwise you'll need to re-tag.
and then rename if final, because (as in past) in case of
problems we'd have to test everything the same.
Just as idea ...
Il giorno 05/ago/2011 21:44, Greg Brown gk_br...@verizon.net ha
scritto:
Someone of us has some file to commit before tagging ?
I haven't ...
You may have missed
[
https://issues.apache.org/jira/browse/PIVOT-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13076136#comment-13076136
]
Greg Brown commented on PIVOT-783:
--
I can see the value in adding a Component list
Actually, it just occurred to me that uniqueness, while not strictly
required, should certainly be encouraged. If you added the same task to a
ParallelTaskGroup's task sequence more than once, you'd basically get
serialized behavior, since only one thread could run the task at a time. So
So Task would need additional execute methods which take an
ExecutorService to use for the execution. (As you suggested earlier).
Yeah, I think this would be much cleaner.
[
https://issues.apache.org/jira/browse/PIVOT-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073517#comment-13073517
]
Greg Brown commented on PIVOT-780:
--
Wasn't there some discussion about allowing a caller
get executed. That is where a bit of documentation
comes in handy.
On 1 August 2011 20:26, Greg Brown gk_br...@verizon.net wrote:
I think the strongest argument for Group is that allowing duplicates could
result in confusing behavior. Making it a Group ensures that the intent is
clear
Here's a thought - maybe TaskGroup itself should also be deprecated. I'm
wondering if it might encourage bad development practice. While it allows you
to execute multiple tasks in the background, it doesn't return until all of
those tasks are complete. One might argue that a well-designed UI
I'd prefer to make a couple of little changes to Task itself, and
leave the rest to the developer. (Multiple TaskListeners per Task,
This could be done with a composite TaskListener implementation, so I don't
think the API would need to change to accommodate that.
and ability to execute a
that works, even if simple, but if generate
confusion I agree to deprecate it now and remove in 2.1 .
Bye
Il giorno 01/ago/2011 20:40, Greg Brown gk_br...@verizon.net ha scritto:
This could be done with a composite TaskListener implementation, so I
don't think the API would need to change
Can't get to JIRA right now, but this is by design. Since a decorator is not
aware of the component or components to which it is attached, it can't
automatically update the display. It is up to the code that modifies the
decorator's state to call repaint() on any affected components.
On Aug
Hi Chris,
I wasted too much time yesterday realizing that TaskGroup
TaskSequence don't use the java.util.concurrent.ExecutorService that
might be passed to their constructors.
If I understand the issue, I think you mean that these classes are not
guaranteed to execute their subtasks using
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071664#comment-13071664
]
Greg Brown commented on PIVOT-778:
--
Way back, I believe we were doing something like
If I understand the issue, I think you mean that these classes are not
guaranteed to execute their subtasks using the same ExecutorService that
they were given. Is that correct?
No it is a little more than that. When a standard Task is created, it
either uses a default ExecutorService or
If you want the sub-tasks to use the same executor service, you can just
pass that service instance to the sub-task constructor. If you pass the
fixed thread pool service to each of your individual tasks, you will get the
behavior you want.
Yes, that is what I discovered. I end up
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown resolved PIVOT-694.
--
Resolution: Fixed
I just checked in what should be a fix for this. Please re-open if the problem
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Brown reassigned PIVOT-694:
Assignee: Greg Brown (was: Sandro Martini)
Improvement in ListButton clear() method
[
https://issues.apache.org/jira/browse/PIVOT-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071761#comment-13071761
]
Greg Brown commented on PIVOT-694:
--
I'll try even on other components to verify the same
[
https://issues.apache.org/jira/browse/PIVOT-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071776#comment-13071776
]
Greg Brown commented on PIVOT-778:
--
Actually, since it is a volatile image, a weak
This fix only applies to ListButton.
I understand this, I'm thinking to make similar tests on other components
that contains some data and could be selected, and see after something has
been selected, if clear reset even the selection ... for example in
ListView/TableView/TreeView/etc.
The Javadoc says pretty much the same thing as I wrote above:
With the crucial exception of how they accomplish what they
accomplish, and in particular, the use of a supplied ExecutorService.
I agree that the Javadoc could provide more detail. But the fact that TaskGroup
and TaskSequence
I suppose I saw it as a ParallelTaskExecutor or TaskGroupExecutor, and
not a ParallelTask or TaskGroupTask. This is probably where the
initial confusion came from.
I can understand that. OTOH, TaskGroupTask (or ParallelTaskGroupTask) is sort
of verbose and arguably redundant, and as you
By that logic, we'd need to qualify every class in the frame work. E.g. we
wouldn't just have a Button, we'd have a ButtonComponent. That is obviously
overkill, and I think it would be overkill here as well.
On Jul 27, 2011, at 1:11 PM, Chris Bartlett wrote:
On 27 July 2011 23:43, Greg Brown
Yes, that absolutely makes sense. The fact that it says class draws attention
away from the fact that it is actually a Task.
On Jul 27, 2011, at 1:13 PM, Chris Bartlett wrote:
On 27 July 2011 23:37, Chris Bartlett cbartlet...@gmail.com wrote:
So I might have approached it differently if ...
Right - and I'm just explaining why they are not named that way. :-)
On Jul 27, 2011, at 1:22 PM, Chris Bartlett wrote:
(I was/am not pushing to change the names - just explaining how I came
to the conclusions I did)
Actually, I'm not sure that logic does follow. Obviously the
Component suffix is (sanely) not used, but plenty of others are.
We have used suffixes where there is no common alternative. For example, we
have TabPane but not AccordionPane. Similarly, we have
org.apache.pivot.web.Query, not
Thanks for bearing with me. I assure you these are genuine
questions asked because I get the impression you have studied API
design quite a bit, or at the very least have an interest in it, and
some strong opinions. (What other kind are worth a damn?)
:-)
We have used suffixes where there
I think that making TaskGroup a Group was a mistake on my part. There is no
need to ensure uniqueness here.
Actually, it just occurred to me that uniqueness, while not strictly required,
should certainly be encouraged. If you added the same task to a
ParallelTaskGroup's task sequence more
[
https://issues.apache.org/jira/browse/PIVOT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071056#comment-13071056
]
Greg Brown commented on PIVOT-776:
--
I imagine that mouse wheel events would be ignored
[
https://issues.apache.org/jira/browse/PIVOT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071068#comment-13071068
]
Greg Brown commented on PIVOT-776:
--
I wouldn't say that I find the Windows behaviour
I don't understand the question. Can you provide a little more context?
On Jul 22, 2011, at 12:11 PM, DreamTangerine wrote:
Any progress ?
How I can help ?
Thanks
DreamTangerine.
After reading this
http://apache-pivot-developers.417237.n3.nabble.com/Drawing-in-SWT-or-WPF-td2169321.html#a2172900
I thought that was some project trying to drawing in SWT and WPF and
OpenGL, is any project ?
It is something we have talked about occasionally in the past, but nothing has
That was supposed to say '...if there is no *focused* Pivot Component...'
I don't foresee too many arguments regarding which Component to
dispatch keyboard events to when the Pivot app has no Components!
Ah, that makes more sense. :-)
I have seen occasions where one OS window (MS Windows XP
[
https://issues.apache.org/jira/browse/PIVOT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069158#comment-13069158
]
Greg Brown commented on PIVOT-774:
--
I think that patch may prevent the scroll timer from
The timer is used to periodically scroll the selection up or down by one row
when the caret moves outside of the text area's bounds. TextInput does
something similar for horizontal scrolling.
On Jul 21, 2011, at 3:52 PM, Edvin Syse (JIRA) wrote:
[
[
https://issues.apache.org/jira/browse/PIVOT-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069200#comment-13069200
]
Greg Brown commented on PIVOT-774:
--
During a drag operation (left mouse button down/mouse
[
https://issues.apache.org/jira/browse/PIVOT-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068320#comment-13068320
]
Greg Brown commented on PIVOT-720:
--
What if the unprocessed key strokes are sent
A new method, Display#getActiveDisplay(), would return the Display considered
to be active in the eyes of the current OS/application.
The active display is defined by the active native window. It is independent
of the active Pivot window.
Only Pivot frames show an active state (and then,
Display#getActiveDisplay() would be useful, since the (global)
UnprocessedKeyHandler could use it to dispatch to the active Display. But
that's kind of a workaround for what I was hoping to get. In the referenced
thread, Chris and/or I suggested that there be another step in the
pseudocode
I don't want to presume to speak for Bill (hopefully he will be able
to comment soon), but I thought this was about having a desktop app
with multiple Displays in multiple 'native OS windows'.
That's what I had assumed too, but in that case each display is likely to be
hosting a maximized
The site probably hasn't been rebuilt since that link was added but I'm not
sure. Todd is the most knowledgable about site deployment issues.
G
On Jul 20, 2011, at 7:00 PM, Sandro Martini wrote:
Hi Roger, I'm sorry but I don't have a clear idea on this.
Maybe Greg or Todd can say something
[
https://issues.apache.org/jira/browse/PIVOT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065903#comment-13065903
]
Greg Brown commented on PIVOT-751:
--
As noted, the bogus event is fired because
I think this is really cool. My only question is - how useful do developers
consider the existing accordion behavior (only one panel open at a time)? If
there are still use cases for it, then it probably makes sense to retain as its
own component. If not, then it could probably be dropped.
But
The actual org.apache.pivot.wtk.Accordion class could still
remain, but its functionality could just be replaced by the relevant
part of this technique of stacking Expanders. So it would pretty much
just become a glorified vertical BoxPane containing Expanders.
That's sort of what I was
This is an interesting question. Why might a web designer want to use this
technique versus discrete images?
On Jul 13, 2011, at 10:37 AM, Chris Bartlett wrote:
(Forwarded from the user list)
Edvin,
I can definitely see the value of being able to target a smaller
'chunk' of a larger
This is an interesting question. Why might a web designer want to use this
technique versus discrete images?
Look at this one:
https://www.syse.no/files/gfx-dark/icons_64x64_cp.png
That's a single http request instead of hm... MANY :)
That was my first thought - that it was an
I agree that one mostly bundles the resources in a Pivot app, but the need is
to reuse existing web-sprites.
OK. It does seem like providing the ability to specify some sort of clipping
region might make sense. In such sprites, are the icon sizes generally fixed?
Or are the images likely to
OK, so specifying a clip region, rather than a row/column and icon size, would
probably be best.
I wonder if this would be best implemented in Picture rather than ImageView?
On Jul 13, 2011, at 11:25 AM, SYSE | Edvin wrote:
Den 13.07.2011 17:22, skrev Greg Brown:
I agree that one mostly
A single image might contain all icons required for a specific piece
of functionality. They might all be required up front, or at some
point in the app's lifecycle, so it is not necessarily true that more
is being held in memory than is required.
True, but if the sprite image contains a
1 - 100 of 1395 matches
Mail list logo
