Obsolete
Status Update
Comments
ex...@gmail.com <ex...@gmail.com> #2
This is a must!
[Deleted User] <[Deleted User]> #3
To give a little context to the need for this. For projects where multiple
applications are involved and they share quite a few custom views, it would be nice
to allow whatever version control software someone is using to dynamically link a
library of these views. The problem is that you can't just pre-generate the R file
for these custom views since it may overlap with the R file for the application.
Currently, the only way to manage this is to copy files from the library over to the
project needing the custom views. This is a nightmare for version control.
A simple solution for this would be to allow subfolders. This would allow, say,
someone using svn to just set externals inside the values folder, so different files
may be included which would be compiled as part of the app's R.java file.
So, this would allow someone to set externals for custom views in the source folder
and then set resource dependencies as externals inside the subsequent res subfolders,
and voila, it would be easier to manage the custom views library and any change to
the library, through svn, would be reflected next time someone syncs with the repository.
applications are involved and they share quite a few custom views, it would be nice
to allow whatever version control software someone is using to dynamically link a
library of these views. The problem is that you can't just pre-generate the R file
for these custom views since it may overlap with the R file for the application.
Currently, the only way to manage this is to copy files from the library over to the
project needing the custom views. This is a nightmare for version control.
A simple solution for this would be to allow subfolders. This would allow, say,
someone using svn to just set externals inside the values folder, so different files
may be included which would be compiled as part of the app's R.java file.
So, this would allow someone to set externals for custom views in the source folder
and then set resource dependencies as externals inside the subsequent res subfolders,
and voila, it would be easier to manage the custom views library and any change to
the library, through svn, would be reflected next time someone syncs with the repository.
[Deleted User] <[Deleted User]> #4
This is not a tool issue but a framework issue. That's how the framework and aapt are
designed.
designed.
af...@gmail.com <af...@gmail.com> #5
This is ridiculous in massive applications - it's a must.
[Deleted User] <[Deleted User]> #6
This should change priority, it's very hard to maintain something with a lots of view, custom or otherwise.
en...@google.com <en...@google.com>
kn...@gmail.com <kn...@gmail.com> #7
for the love of all that is sane... allow me to organize my large project better and more easily
Description
Reference bug
Tests where made with the emulator and verion Froyo 2.2 API level 8.
Test page is simple.
<html>
<body>
<div id="x" contentEditable="true" style="width:160px; height:100px; border: 1px solid black;">
edit <strong>me</strong> now!
</div>
</body>
</html>
How to test: Make a simple html page with the code above, go there with the browser, click/point inside the editable area.
What happens: Not a lot.
What should happen:
The onscreen keyboard should come out, and a caret should be visible (seperate bug report submitted for caret issue).
Was not able to activate the onscreen keyboard by holding down the menu button as described by the referencing bug report either.